Slashdot Mirror
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.
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.
The enemies of Democracy are
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.
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, 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?"
"Any fool can make a rule, and any fool will mind it."
--Henry David Thoreau
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.
Interested in open source engine management for your Subaru?
How many of you think this story got posted just to use that cool icon?
--
python -c "x='python -c %sx=%s; print x%%(chr(34),repr(x),chr(34))%s'; print x%(chr(34),repr(x),chr(34))"
If you can't remember if you're running BIND or not you probably shouldn't ;-)
~~~~~ BigLig2? You mean there's another one of me?
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.....
Maybe one of these solutions will work for you.
"Science is about ego as much as it is about discovery and truth " - I said it, so sue me.
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.
"Science is about ego as much as it is about discovery and truth " - I said it, so sue me.
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".
The whores get mad when the sluts give it away for free.
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
I was running bind 8 in a chroot jail and when /var/run
I built bind 9 it barfed a little, but all I
really needed to do was make the
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
demi
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.
-- To bloody go where no man has gone before.
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.
--
Enjoy Y2K? Roll-on Year 2037!
It's all in the docs/misc/migrating file in the 9.1.0 tarball...
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.
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:
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.
I'm old enough to remember when discussions on Slashdot were well informed.
One Ring to find them,
One Ring to bring them all
and in the darkness BIND them.
Hmmm... Interesting.
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.