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

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.