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.

Re:Who needs BIND?

All software has bugs. OK. BIND has a trackrecord of having security related bugs.

Or rather, track record of having known security related bugs, because it is so widely used and hence so widely scrutinized. Whatever it is that you think has less bugs because of less known security issues, ask yourself if it is as widely deployed and as widely scrutinized as bind.

Maybe we should be more forgiving to Microsoft security issues then?

As long as the patch is released in a timely fashion (which means a day or two tops), and they don't attempt to cover up the "issue", then yes we should be. Unfortunately, neither of these things describes Microsoft behavior in most cases.

Debian update instructions

Add the following line to your /etc/apt/sources.list file:

deb http://security.debian.org/ potato/updates main

Then do a:
apt-get update
followed by a:
apt-get upgrade

DONE.

Who needs BIND?

I don't mean this as a troll, but it seems that BIND has more security vulnerabilities than any other piece of software. I know someone brings this up on every DNS related post, but I think more people should try djbdns [cr.yp.to], with which I have been very impressed since I started using it about six months ago. I have heard that BIND 9 is supposed to be an improvement, but with BIND's history of security problems I'm not sure if I would trust even this new improved version. I think it is better to go with software that has already demonstrated its good security, like djbdns has.
---------------------------
"The people. Could you patent the sun?"

A couple of important points

First, stay away from Bind 9. It has yet to incorporate all the features of version 8, and is still in its infancy. There are many security holes that have been found it it, and I suspect many that have not. You'd be best to stick with 8.2.3.

Second, and more importantly, DO NOT RUN A NAMESERVER AS ROOT. There are -u and -g flags when starting named that allow you to set which user the nameserver will run as, much in the same way that IRC servers are run as unpriveleged users. Then if the server is compromised, you've only lost an account and not the whole system, assuming no one will be able to hit you with a local exploit.

Ok

How many of you think this story got posted just to use that cool icon [slashdot.org]?


--

Re:aka "named"

If you can't remember if you're running BIND or not you probably shouldn't ;-)

Bind 9 not related to bind 8/BSD nto safe if.....

From what I understand and have read BIND 9 is a total rewrite, supposedly with security in mind. No code was used from BIND 8 or BIND 4. BIND 8 still had a great deal of code from BIND 4, which itself was written VERY VERY long ago in a "programmers drunken orgy" of coding.

BSD users are still screwed if they downloaded the source and compiled from source. The changes to BSD's BIND 4 are only for those people that used open BSD's implementation of BIND4.

There are severl alternatives, and having used them all, we had to switch back to bind because of interoperative problems or performance issues. Some solutions are.....

• djbdns [cr.yp.to]
• Windows DNS server [microsoft.com]
• Dents [sourceforge.net]
• lbnamed in PERL [stanford.edu]

  Maybe one of these solutions will work for you.

Re:djbdns is the way to go!

It all depends if you have machines/IP's to spare. djbdns requires seperate machines for almost everything. If you want your load balancing DNS server run this, resolver run this, master/root server run this. While I use a good deal of Bernstein software, and genearlly really like it djbdns wasn't up to snuff. The other thing I'm worried about is that the software will be left to rot.

Qmail appears abandoned. Many people are making patches, but what a pain in the ass, get the source then apply the 3 patches you need and hope they work together. Qmail is a great program, BUT if the author isn't going to keep improving it, then he should turn it loose to those that are.

aka "named"

As a partially informed/ignorant Linux user, I went to see if I was running "bind"...

It's probably worth mentioning that the program "named" (as seen in the service control activity panel of LinuxConf) is "bind".

djbdns is the way to go!

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 [cr.yp.to]

Re:Chroot jail with bind 9? - answer

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

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

Re:OpenBSD Immune

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.org]
OpenBSD 2.7 http://www.openbsd.org/errata27.html [openbsd.org]

The rebuild and install is trivial.

--

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

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

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 [theregister.co.uk].

Re:In the wild

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 [pgp.com]:

"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?

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

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

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 [e-mail]; 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...

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

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 [securityfocus.com] and is probably the definitive how-to in existence at the moment.

Hope that helps.