BIND4/8 Vulnerabilities (LONG)

Re: BIND4/8 Vulnerabilities (LONG)

From:

Date:

Time:

At 1:32 PM -0600 11/12/02, Mia's Virtual Post Office wrote:
>Sorry for the long post.. Is there anything to worry about here with
>QNDS and OSX?

[snip]

>Where disabling recursion is not possible, a temporary workaround exists that
>may protect perimeter DNS servers from the remote compromise vulnerability.
>Due to the nature and organization of stack variables, exploitation is much
>easier if the attack is embedded within TCP DNS traffic. It is unclear at this
>time if this attack is possible with UDP traffic on certain architectures. The
>UDP protocol is used for most DNS related queries and responses, except large
>responses and zone transfers between primary and secondary DNS servers.
>Therefore, perimeter DNS servers should be protected by filtering TCP port 53.
>This workaround will block the exploit technique demonstrated by X-Force, but
>this solution should be examined carefully to determine if it would not affect
>normal DNS functionality. This workaround is meant as a temporary solution to
>offer some level of protection before a patch can be applied.

OK, let's apply a little common sense to the paragraph above.

1. The first vulnerability, the buffer overflow, is highly unlikely
to be triggered by a UDP packet, since UDP is restricted to 512 bytes
per packet. Thus, it's almost inconceivable that this could be done
over UDP. So a block on the TCP port will stop this attack - your
server's security will not be compromised.

2. The other two vulnerabilities involve (a) a UDP-based attack, and
(b) invalid data. Neither of these will be stopped by a block on the
TCP port, though they both simply crash the machine - a much smaller
annoyance than the first vulnerability.

So the TCP block, which we've discussed before on this list (in
relation to classic Mac OS) and with which nobody's ever reported a
problem, can be described as essential security. Remember to allow
TCP-based connections from slave servers to their masters.

However, that leaves your servers vulnerable to DoS attacks. Since
QuickDNS uses BIND's name server on most platforms, the quickest way
to avoid this is to update to BIND 9. (Note that QuickDNS 3.5.x
doesn't support BIND 9 - this support was added in QuickDNS 4.)

I wrote the following instructions for a customer earlier today. They
assume some level of ability with the command-line shell.
____________________________________________________________________

I'm assuming the DNS server QuickDNS Remote 4 installed. QuickDNS
Central 4 is not affected in any way, and will therefore be
completely ignored here.

I'm also assuming that the named configuration file directory is
/var/named, which is the most common location. Check /etc/named.conf
to be sure - if the include statements in that file lead to files in
/var/named/conf, then /var/named is the configuration directory.

Upgrading with QuickDNS installed is very similar to upgrading
without QuickDNS installed.

Step 1: Take down the DNS services, including named and qdnsremoted.
On Linux, this can be done as follows (as root):

# /etc/init.d/named stop
# /etc/init.d/qdnsr stop

On Mac OS X:

% sudo qdnscontrol stopnamed
% sudo qdnscontrol stopremoted

Step 2: Install BIND 9, version 9.2.1 or later. Use an RPM, or source
code, or whatever other means is available. Make sure that
/etc/init.d/named is updated appropriately. Make sure that
/etc/named.conf is not modified or replaced.

Step 3: Configure rndc, as follows:

On Linux (as root):
# rndc-confgen > /etc/rndc.conf

On Mac OS X (as an administrator):
% sudo rndc-confgen > /etc/rndc.conf

Note that rndc-confgen should have been installed in the same
location as the other BIND 9 binaries, such as either /usr/sbin or
/usr/local/sbin. Make sure that its location is in your PATH
environment variable before executing the above, or else prefix its
name with the proper path (e.g. "sudo /usr/local/sbin/rndc-confgen >
/etc/rndc.conf").

Step 4: Configure named for rndc, using a text editor with superuser
privileges:

- Look in /etc/rndc.conf. There are roughly 12 lines of actual
configuration data, plus approximately an equal number of lines of
comments at the end that are meant to be integrated into the named
configuration. (Don't put the indicated data in /etc/named.conf,
though.) For this named configuration data, when you use it, strip
the leading "#" characters from each line.

- Put the "key" statement (4 lines) from rndc.conf in
/var/named/conf/user_before.

- There's already a "controls" statement in
/var/named/conf/user_after. Replace it with the one from rndc.conf.
In other words, remove the "unix" substatements and add the "inet"
substatement.

- If you decide to change the default settings in rndc.conf, contact
support for help in making sure you don't disable QuickDNS Remote's
ability to control named, since QuickDNS Remote doesn't read
rndc.conf (nor does it use the rndc utility - it has this
functionality built in).

Step 5: Start up the named and qdnsremoted services. Once again, on
Linux, this can be done as follows:

# /etc/init.d/named start
# /etc/init.d/qdnsr start

On Mac OS X:

% sudo qdnscontrol startnamed
% sudo qdnscontrol startremoted

Step 6: Check for errors. QuickDNS Remote logs to syslogd (which
usually writes logs to one or more files in /var/log). named logs
some stuff to syslogd, and other stuff to a log file at
/var/named/quickdns.log (by default). Do this after starting the
services and also after saving a change to a zone - QuickDNS will use
the new rndc key to communicate with named and make it reload the
changed zone.
____________________________________________________________________
Chris Buxton Men & Mice
support@menandmice.com Making DNS Easy

Sales:
888/4-DPOINT

Support:
858/452-3696