Running BIND 4 or 8? Upgrade!

The Dev was the first of several zillion to point out that security holes were found in BIND. The detailed table of known vulnerabilities will help clarify (and it has tarball links too), but the short version is, if you're running BIND 4 or BIND 8, set aside some time today to upgrade to 4.9.8 or 8.2.3 (not beta, betas of 8.2.3 are vulnerable). And now's a good time to reconsider version 9, too. SecurityFocus warns that the last time a BIND hole of this magnitude was found, it was followed by a "cyber-crime wave." Exploits for these holes were successfully created by COVERT Labs, but nobody seems to know whether they're in the wild yet. Obviously, they soon will be. Post your questions and answers about upgrading below.

Comments

djbdns is the way to go!

[Tracy Reed]

I switched to djbdns a few months ago because I just KNEW something like this would happen. Now I am glad I did! Bind is such a clusterf*ck. :(

http://cr.yp.to/djbdns.html

Re:Chroot jail with bind 9? - answer

[demi]

I was running bind 8 in a chroot jail and when
I built bind 9 it barfed a little, but all I
really needed to do was make the /var/run
under the chroot directory world writable. And
bind 9 complained about not having a $TTL
directive in my zone files. Once I fixed those
things, I was up and running without having to
change named.conf.

I found the following things helpful:

named -g -u <user> -t <chroot_dir>

this runs named in the foreground without
writing to log files and lets you see what's
going on with it for troubleshooting. I
also used ktrace to good effect: use truss
on Solaris, strace on Linux and ktrace on
BSDs and you'll see what named is trying to
do (in particular, which files it's trying to
open).

I'm running OpenBSD and (now) BIND 9.1

Red Hat Releases updated RPMs

[bluehell]

Get the not yet announced RPMs of bind-8.2.3 at Red Hat's FTP-Server's Update-Section or the Mirrors. Goes back even to Red Hat Linux 5.2.

Re:OpenBSD Immune

[karot]

This is not true. OpenBSD have of course merged the required fixes already, and they can be found at:

OpenBSD 2.8 http://www.openbsd.org/errata.html
OpenBSD 2.7 http://www.openbsd.org/errata27.html

The rebuild and install is trivial.

--

Re:What's it take to go from BIND 8.2.x to 9.1 ??

[ivarch]

Couple of things changed, nothing drastic. I changed over to 9.1.0 this morning and basically had to delete 1 line (about fetch-glue) and put in another (auth-nxdomain yes|no). That was just 2 changes in /etc/named.conf, for something like 337 zones on a primary server. Not painful at all. :-)

It's all in the docs/misc/migrating file in the 9.1.0 tarball...

Re:In the wild

[doctor_oktagon]

Well they're on /. , i don't think they can be "in the wild" much more than they are now.

Because this announcement is on slashdot does NOT imply there are exploits available in the wild for these security holes.

An exploit "in the wild" implies it is generally available to any script k1d that wants to download it, and as yet there are no "known" attack exploits available on the popular crack download sites.

This does not mean there are no exploits available. A very skilled cracker (or hacker doing it on a theoretical basis) may already have worked out what code he can get by the BIND signiture parser buffer overflow, and thus what he can get the CPU to run.

I hasten to add though that because of the way BIND parses it's input to this buffer, the attacker cannot actually run arbitrary code, but only use code containing characters which can get through the parsing routine.

Excellent description at The Register.

Re:In the wild

[h2odragon]

I can report scans of port 53 with "interesting" payloads seen as early as 2am GMT.

The BIND 4 hole(s) is/are going to be a BITCH to exploit, certainly not impossible; but hard enough that it won't be suprising if such never sees wide distribution. Quoth the original advisory:

"In order to trigger this overflow, an attacker needs to get BIND to cache an NS record with a very large length. Furthermore, the attacker needs to cache a record for the resolution of the NS record that contains one of the problem conditions for the logging. This is achievable by sending a query to a recursive name server, asking it to resolve a large name that is under the authority of a malicious name server. The malicious name server then needs to refer the request to another name server also with a large name, and provide an additional record giving an invalid address for that name server.

The limitations placed upon the character set allowed in domain names makes the construction of a viable return address difficult. However, there is a potential for an attacker to make the name server return into memory that the attacker has forced the name server to allocate. In this case, vulnerability is contingent upon the location of the heap and the amount of memory available, as well as whether or not the operating system has a policy of lazy swap page allocation as opposed to an eager reservation policy. COVERT has verified that it is possible to exploit named running under Linux by growing the heap to sizes that far exceed that amount of memory and swap available. This was performed by utilizing specific patterns of memory allocation that maximize untouched memory."

Re:Who needs BIND?

[Barbarian]

I doubt djbdns has received the attention that BIND has. If djbdns was used on every server instead of BIND, there'd probably be problems found with it too.

Re:Debian update instructions

[nchip]

Assuming that your dns server hasn't been compromised!

When making security updates, verify first the debs really are the ones announced on:

http://lists.debian.org/debian-security-announce -0 1/

A mailing list you should be subscribed to, if you run public services with debian. Relying on /. for security news/instrucions is probably the stupidest thing one can do!

Re:Avoiding This Altogether

[Simon Brooke]

Most security holes come down to two things. One is allowing unvalidated input from untrusted users to be passed to any sort of general purpose command interpreter. This was a prime source of holes in early CGI scripts; for example, if you ask a user for an email address and then use the mail utility to send mail to it, and the user types me@mydomain.com; cat 'hax0r::0:0:lee7 hax0rs ownz you sux0rs:/:/bin/sh' >> /etc/passwd then you've just lost your machine.

The other is accepting unchecked amounts of input from untrusted users. Remember that C (unlike, for example, Pascal, Java or LISP) does no bounds checking, so you have to implement bounds checking yourself.

If you do the equivalent of:

char buffer[ BUFFLEN];
int i = 0;

while( ! feof( stdin))
{
buffer[ i++] = getchar();
}
buffer[ i] = '\0';

That's going to lead to a buffer overrun which someone can exploit. If you do the equivalent of:

char buffer[ BUFFLEN];
int i = 0;
int maxinput = BUFFLEN - 1;

while( ! feof( stdin) && i < maxinput)
{
buffer[ i++] = getchar();
}
buffer[ i] = '\0';

Then you're reasonably safe. But to be safer still, don't use C to write daemons which take input from untrusted third parties, and don't run daemons as root - give each it's own separate role account.

A quote seems appropriate...

[ASCIIMan]

One Ring to rule them all,
One Ring to find them,
One Ring to bring them all
and in the darkness BIND them.

Hmmm... Interesting.

Re:Avoiding This Altogether

[DrWiggy]

Does anybody out there have links to some good reference material on this?

Sure. There is a mailing list over at SecurityFocus called SECPROG that discusses secure programming practises. The idea is to produce a white paper that describes how to write secure code. The draft can be seen here and is probably the definitive how-to in existence at the moment.

Hope that helps.