Bind 4 and 8 Vulnerabilities 408
eecue writes "The world's most popular DNS package is once again vulnerable. Even the advisory says it's only a matter of time before worms are written.... just like a couple years ago. I guess this is why i run tinydns."
Escape (Score:5, Informative)
Re:tinydns: internal and external views? (Score:5, Informative)
Yes. This page shows you how http://cr.yp.to/djbdns/tinydns-data.html [cr.yp.to]
"I guess this is why i run tinydns." (Score:4, Informative)
From the advisory:
"BIND 9 was not affected by any of the vulnerabilities described in this advisory."
patches already available (Score:5, Informative)
Does MS fix their vulnerabilities that fast? Judging by the number of klez variants in my inbox, I'd say "no".
maradns (Score:3, Informative)
Re:And I guess... (Score:3, Informative)
The more pressing concern is that parts of bind4 and bind8 are so far ingrained in standard system libraries and other binaries that simply changing to use bind9 as your nameserver doesn't remove the old, buggy code from your system.
Don't slashdot ISC yet (Score:3, Informative)
Tips (Score:5, Informative)
[] May I suggest djbdns [freshmeat.net] rather than BIND? Its creator says "every step of the design and implementation has been carefully evaluated from a security perspective. The djbdns package has been structured to minimize the complexity of security-critical code. dnscache is immune to cache poisoning. It is advisable to use the package as a secure alternative to BIND."
[] May I suggest Dnsmasq [freshmeat.net], which is described by its creators as a "lightweight, easy to configure DNS forwarder designed to provide DNS (domain name) services to a small network where using BIND would be overkill".
Re:And I guess... (Score:3, Informative)
Or you could use bind 9... (Score:5, Informative)
It uses RFC-specified zone file format, it's extremely functional (internal/external views of DNS based on query source, TSIG authenticated DNS transactions, DNSSEC authenticated DNS records).
In the couple of years the bind 9 code has been out there, the only vulnerabilities it's had caused the server to shut itself down immediately, as it realised something was wrong with its input. That's likely to be it's only failure mode in the future - stick a wrapper around it that restarts it when it dies, and you'll be right as rain.
BIND9 (Score:5, Informative)
BIND 8.3.3 is the latest version of ISC BIND 8. We strongly recommend that you upgrade to BIND 9.2.1 or, if that is not immediately possible, to BIND 8.3.2 due to certain security vulnerabilities in previous versions. 8.3.3 contains a security fix in libbind. If you have BIND 8.x you need to upgrade. [isc.org]
Re:Did ISS tell bind maintainers? (Score:5, Informative)
They are pretty pissed about it.
Alan Cox's response was "Well we can all express our deep regret at the inability of the ironically named ISC to work with the internet and society in all the announces."
BTW, Bind 9 does not fix all of these probems and the fixed versions will be out next week.
This is not the first time that ISS has released information like this without informing the vendors ahead of time.
/. should be more precise with security flaws news (Score:3, Informative)
Bind 4.x and 8.x are vulnerable to this.
Version 9, which is a complete rewrite from scratch
and the version that everyone running bind should be using,
does not suffer this security flaw.
Slashdot editors should take an extra care when posting
news like this to avoid FUD and unnecessary panic.
Re:And I guess... (Score:5, Informative)
Besides, there are some good security points you should be doing anyway on the server. Unless you must have it, turn off recursion:
acl safenets { 127.0.0.1/32; your.internal.ips/??;}
options {
allow-transfer { safenets; };
allow-recursion { safenets; };
}
between that, a solid chroot, and a solid setuid, you'll have beaten 99% of the bind problems you'll have.
Who uses bind4 anymore department? (Score:5, Informative)
and read this [sigmasoft.com] for why
Re:Escape (Score:3, Informative)
There hasn't been a djbdns release since 12-Feb-2001 [freshmeat.net] and the project is bound to go stale sooner or later if djb does not renew his interest. How many companies or networking professionals out there are going to use DNS software which has a single human point of failure? I won't even go into the "hit by a bus" argument.
Granted, djbdns comes with some cute gimmicks like the "security guarantee [cr.yp.to]". But for all of BIND's problems, the fact that it's open source makes it the better option in this case. Better the devil you know..
Re:tinydns: internal and external views? (Score:4, Informative)
This shows, using the shorthand "in" for internal and "ex" for external, the syntax for creating the equivelant of bind's views. Its pretty flexible. And not hard at all.
I do wish that djb could have made his format a bit more consistant, but when I think about it its probably impossible considering that DNS requires some oddbal fields. Having written a parser, its pretty darn easy to read and parse, especially compared to trying to compare it to the bind format after an axfr, where it keeps redifining "@".
-Peter
Not So Strawman Worms (Score:5, Informative)
The only "gotcha" in that exploit is that an attacker needs to control a DNS server which the victim DNS server queries. Thus it is a passive attack, the victim must query you, not the other way around.
That is why the attacker uses a passive worm: The worm infects a DNS server, which in addition to being the local DNS server, serves as the authoritative master DNS server for some domains. When another DNS server queries the infected authoritative master, the authoritative master's response is designed to compromise the requesting server.
This compromise is followed by a transfer of the worm code itself, and now the victimized server is now infected as well.
As I said, this doesn't scan, which makes it particularly nice and stealthy.
You could also make an active scanning worm as follow: There are 2 kinds of nodes, authoritative DNS servers and other DNS servers. If you infect an authoritative DNS server, the worm knows it. Otherwise, it knows the authoritative DNS server it was infected from.
The worm "scans" by sending DNS queries (ideally with forged from addresses) which will trigger a lookup from the known corrupted authoritative server. This can then go through the net, rather noisily, and infect all servers which accept remote queries. This process can be sped up considerably by looking through the local cache for a list of all DNS servers that the corrupted machine knows about. Rough guess? Less than an hour to infect everything which can listen to the net, and you still have the passive attack to get DNS machines behind firewalls etc.
The fortunate thing: Although the possible worms are either very fast (lots of vulnerable machines, topological speedup from using the cache) or very stealthy (no scanning at all, a contageon strategy), both techniques require a fair amount of BIND specific programming to develop and release: You need to not only craft the exploit, but keep bind running and transmit the exploit.
So no kiddiot can simply drop exploit code into scalper.c and get it to work, instead there is a considerable amount of programming needed. So we do have a significant time window to patch machines, but they do need to be patched because it is a very "worm friendly" exploit pattern.
Why I LOVE Red Hat Network (Score:3, Informative)
Before I even realized that this doesn't apply to me, (I'm using Bind 9) all the updates had been downloaded and applied.
And, I guess, in a week or so, I'll get an email from Red Hat letting me know that I should be running up2date again...
-Ben
I like MyDNS (Score:2, Informative)
0.9.5 (development copy at http://mydns.bboy.net/beta/) also supports PostgreSQL.
Of course, I am biased.
Re:Escape (Score:2, Informative)
Code doesn't "go stale." djbdns works, and it's not going to rot and stop working if Dan doesn't change it.
As for his losing interest, he's recently revamped all of the djbdns documentation and has been active on the djbdns mailing list.
Re:And I guess... (Score:5, Informative)
You still get the same effective service without nearly as much risk of random idiots exploiting buffer overflows.
Re:Who uses bind4 anymore department? (Score:5, Informative)
Based on the ISS and CERT info it looks like OpenBSD's named is vulnerable. However, since named is run chrooted on OpenBSD this shouldn't be such a big deal. When bind 4.9.11 comes out we will spin a patch.
Note that we do not appear to have the resolver buffer overflow described in http://www.isc.org/products/BIND/bind-security.ht
(looks like we fixed it in 1997).
Please pass on the crack pipe! (Score:3, Informative)
Besides, the project has not been updated because there is no need. djbdns just works. If you need more functionality than the stock package provides, there are several patches. I know because I wrote (and publish) one [www.fefe.de].
The rest of your "arguments" I will not go into because they rely on flawed assumptions.
Re:Escape (Score:3, Informative)
If you own a piece of copyrighted work, you can alter it for your own use legally. Try this. Pick up the newspaper, and put a mustache on GW Bush. It is legal !!!
Now, for software, the same conditions hold. Download djbdns. Add the comment
Omigod. What a revelation.
Anyway, the main barrier placed up by djb is that it would be tough to port djbdns to a non-UNIXlike OS, and tough for a distro to carry it (since the distro will need to distribute the source, potentially a patch, and have it build on install). Debian DOES distribute qmail. And a patch, and it builds on install. You are definitely given EXPLICIT permission by djb to distribute the latest source tarballs that are accessible on his website.
As far as the other stuff, well, a large patch community is built around qmail and tinydns, and DJB is quite supportive. You get the source, and the ability to change it for personal use. And the ability to distribute patches to the source. Isn't that enough ?
How to remove tinydns ? (Score:2, Informative)
But in case your installed it on your system in the "standard" location (/usr/local) (Note: I used dnscache and dnsclog as the users to create), here is a little script to "wipe" it (remember to have bind ready to take over after you kill the sv processes remaining).
rm -rf
rm -rf
rm -rf
rm -rf
rm -rf
rm -f
rm -f
perl -pi.old -e 's%^(SV:123456:respawn:/command/svscanboot)%#$1%'
userdel dnscache
userdel dnsclog
cd
foreach i (fghack pgrphack readproctitle supervise svc svok svs* envdir envuidgi
d multilog setlock setuidgid softlimit tai64n* axfr* dns* pickdns* random-ip rbl
dns* tinydns* walldns*)
rm -f $i
end
Hope this helps,
-- M
Shameless plug time (Score:5, Informative)
Another option, if one does not need recursive caching is posadis [sourceforge.net]. There is also pdnsd [t-online.de], which only provides recursive DNS service.
Security history of various DNS servers:
Re:patches already available (Score:3, Informative)
Yes. And if the patch is slow in coming out, it's because they are regression testing it. Do open source clients regression test their patches against thousands of machines with different configurations, or just release it as-is and post followup patches if they have problems?
Judging by the number of klez variants in my inbox, I'd say "no".
The only thing that proves is that the majority of users don't keep their systems patched, since Microsoft has made Outlook immune to viruses (yes, IMMUNE COMPLETELY IMMUNE)... been that way for over a year now, maybe approaching 2 years.
Re:Did ISS tell bind maintainers? (Score:2, Informative)
vulns, ISC worked with the vendors, and both of us
worked with CERT and coordinated the announcements.
Paul Vixie
Chairman, ISC
Re:Why I LOVE Red Hat Network (Score:3, Informative)
"Versions of Red Hat Linux since 7.1, and Red Hat Linux Advanced Server
shipped with BIND 9 are are therefore not vulnerable to these issues.
Older releases (6.2, 7.0) of Red Hat Linux shipped with versions of BIND
which are vulnerable to these issues, however a Red Hat security errata in
July 2002 upgraded all our supported distributions to BIND 9.2.1 which is
not vulnerable to these issues."
Re:Escape (Score:4, Informative)
The linuxmafia article is also wrong on several counts.
Please let me know, and I'll fix them.
If you own a piece of copyrighted work, you can alter it for your own use legally.
John Cowan's analysis on license-discuss@opensource.org of the USA Copyright Act's legislative history suggests that modification is not among the rights automatically conveyed. The essay on my site links to a mirror of his analysis, so you're welcome to evaluate its merits for yourself. My only comment was that Cowan "convincingly disputed" Prof. Bernstein's assertion to the contrary. But whether you'll be similarly convinced is entirely between you, Cowan, and the legislative record.
You claim that there my essay is "wrong on several counts", but only cite only one particular on which you seem to disagree (without clearly stating why, other than that handwave about newspapers) -- not with me, but rather John Cowan. Are there other points, that you accidentally neglected to include? Please do detail them, when you have a chance.
As far as the other stuff, well, a large patch community is built around qmail and tinydns, and DJB is quite supportive. You get the source, and the ability to change it for personal use. And the ability to distribute patches to the source. Isn't that enough?
It's very generous, and commendable of Prof. Bernstein to grant that to the user community. In fact, it's about as generous as it's possible to be with proprietary software. Anyone who's content to become dependent on proprietary software might be very pleased with djbdns, qmail, tcpserver, publicfile, daemontools, and other similar proprietary-licensed offerings -- if they like the design (which I happen not to).
Funny how proponents of DJBware just seem completely unable to utter the word "proprietary". I wonder why that is?
Those of us who, other things being equal, prefer open-source code -- which can be forked [linuxmafia.com] in order to prevent the project from dying when its creator dies or loses interest -- will continue to prefer MaraDNS, BIND9, Posadis, CustomDNS, Yaku-NS, etc.
P.S.: I'm sure you'll be equally offended by http://linuxmafia.com/~rick/linux-info/mtas [linuxmafia.com]. Enjoy!
Rick Moen
rick@linuxmafia.com
Don't Blame Sendmail (Re:AMEN!) (Score:4, Informative)
Actually, it's more the other way 'round. People like to blame things on Sendmail. Usually people who haven't looked at it years, if it all. Would you blame the 2.[45] Linux kernels for 1.0's lack of support for fireware or USB.
Neither Sendmail.org nor Sendmail, Inc has a long history of being vulnerable. Commercial OSes have a history of running old Sendmail5.65 distros. Sendmail.org, on the other hand, has a history of being blamed for vulnerabilities it neither caused nor can be responsible for fixing.
It has a history of Slashdolts making ignorant critiques like yours: Sendmail doesn't complain problem about group-readable /usr; it complains about group-WRITABLE /usr. It does complain about group-readable authentication databases.
Show us an option that Sendmail should code around. One that actually exists, I mean! You'll find that (a) satisfying Sendmail without DontBlameSendmail will be more secure and (b) the circumstances are the choice of the OS distro or the installation's Sys Admin (and likely an oversight).
Re:QPL? (Score:3, Informative)
He doesn't need to. djbdns doesn't have a license and doesn't need one: http://cr.yp.to/softwarelaw.html [cr.yp.to]
It would be more accurate to say that djbdns has the default licence that implicitly attaches to creative works by default application of copyright law -- in the absence of an explicit licence grant. The terms of that default licence, described by Prof. Bernstein mostly accurately (other than, according to John Cowan, those concerning modifications [linuxmafia.com]) at the URL you posted, are those of proprietary software, rather than open source. (Thus, any software instance issued without an explicit licence is proprietary by default.)
BIND 9 has had security holes.
Tell the whole truth, please: A BIND9 version was subject to one type of DoS attack. Sending a specific DNS packet to the daemon triggered that instance going into some sort of test mode where it performed an internal consistency check, effectively shutting it down.
Rick Moen
rick@linuxmafia.com
Re:Shameless plug time (Score:3, Informative)
- djbdns: no reported vulnerabilities
Hurrah to people who know how to write software properly.Re:QPL? (Score:4, Informative)
First there was sendmail. Then qmail. Then, a long time later, other options.
Noted. But I'm talking about how DJB groupies tend to behave today. See for yourself: Look on the various Qmail pages. Read the Qmail HOWTO.
That might have been a reasonable excuse years ago. Today, it looks a whole lot like intellectual dishonesty: Beating up on monolithic Sendmail, especially in the usual fashion that fails to credit it for the major improvement of dropping privilege according to role, is a whole lot more facile rhetoric than comparing it against the similarly-designed Postfix (ne Vmailer) codebase.
First, there was BIND. Then, djbdns. And now, VERY recently, other replacements.
Actually, some (such as Dents) have been around for quite a long time. Most people were not aware of them until after I expanded my essay [linuxmafia.com] to include open-source alternatives to all the proprietary DJB packages. Which in turn I was motivated to do out of annoyance at Prof. Bernstein sending me belligerent e-mails essentially making legal threats (talking about my essay being "against the law" and containing "libel"). Funny how these things work out, isn't it?
I don't think proprietary is appropriate.
That's too bad, because that's what the word means. One key element whose absence makes us consider a package proprietary is not having the right to fork [linuxmafia.com]. Not having that possibility as a safety valve means that the package is at risk of becoming effectively unmaintainable if its copyright holder stops issuing new versions (and doesn't grant additional rights to fix the problem).
Prof. Bernstein is certainly under no obligation to grant such rights, and he's quite generous in granting those he does -- but the only fitting term for the result is "proprietary code".
DJB software provides the user ALL of the GNU freedoms.
That, sir, is simply wrong. Hmm, I don't usually pay a whole lot of attention to Stallman's "four freedoms" essay, since it's a bit too vague to be useful. I prefer the DFSG and OSD, generally.
However [rummaging through the FSF propaganda], Prof. Bernstein doesn't choose to meaningfully grant FSF freedom #4. To quote that essay: "The freedom to redistribute copies must include binary or executable forms of the program, as well as source code, for both modified and unmodified versions. (Distributing programs in runnable form is necessary for conveniently installable free operating systems.) It is ok if there is no way to produce a binary or executable form for a certain program (since some languages don't support that feature), but you must have the freedom to redistribute such forms should you find or develop a way to make them."
His software works dern well, and is free enough for anyone whose concern is getting their work done.
Until the day Prof. Bernstein hangs up his hat, at which point the projects basically become unmaintainable. (Maintaining a codebase solely through source patches against a legacy final-version source tarball wouldn't really be feasible for long.) And that is of course the prospect that hangs over users of all such software.
Rick Moen
rick@linuxmafia.com
Re:Escape (Score:5, Informative)
djbdns has supported client differentiation since January 2001, version 1.04.
For comparison, BIND 9.0.0 was released in September 2000. It was practically unusable. The BIND company now says that BIND 9.0.0 had more than six hundred bugs, many of them quite serious.
Are you saying that you tried djbdns two years ago, had to use BIND 9's ``views'' instead, managed to survive BIND 9's bugs, and haven't looked at djbdns since? If so, take another look. Client differentiation is substantially easier with djbdns than with BIND 9.
Or are you saying that you tried djbdns more recently, and somehow acquired the false impression that it doesn't support client differentiation? If so, how did you acquire that impression? Is there something in the documentation that could be improved?
Re:Escape (Score:3, Informative)
It is just not even close to true. Changes FOR YOUR OWN PERSONAL USE do not come close to the issues related to copyright violation (effects on the author's market for the copyrighted material, or his reputation, etc). This is NEVER a default copyright violation. To claim so reaches the heights of absurdity. Talk to a copyright lawyer sometime instead of someone with his head shoved up his ass.
Those of us who, other things being equal, prefer open-source code -- which can be forked...
I DO prefer code open source code that can also be forked. But I do not think that is necessary for something to be FREE (as in GNU free), although the OSI would include it in their definition of "open source". There are a LOT of relevant freedoms. DJB includes all but redistributing derivatives. That is a LOT, and by no means reason to condemn his work to hell for eternity.
P.S.: I'm sure you'll be equally offended by http://linuxmafia.com/~rick/linux-info/mtas
Not really. I am not so into performance reviews unless performance is an issue for me. My servers are not pegged to the line EVER, performance is a non-issue for ME. What I care about is security and ease-of-use (mainly because they relate to the amount of admin time I need to spend to achieve proper use for my users). And DJB software allows ME, with my very specific small server needs, the absolute minimum admin time to perform as well as I need. And that is all.
Ask most admins, and they will tell you a similar story. The best no-cost software is the one you have to spend the least time dorking with. If it is OSI open source as well, so much the better. If not, well, I'll wait until something better comes along that is OSI open source. But only if DJB's software fails or needs upgrading sometime in the next 20 years. Which is unlikely.
Re:Escape (Score:3, Informative)
Moen's source John Cowan is correct about one thing: namely, CONTU said that users ``should'' have modification rights, not that they ``do'' have modification rights. What Cowan and Moen fail to understand is that (1) CONTU was giving recommendations to Congress regarding changes to copyright law and (2) except for something that isn't relevant here, Congress followed those recommendations.
Cowan says that ``there is no evidence that the right ... was in fact added'' to copyright law. In fact, the evidence is overwhelming. (Cowan logic: if Cowan hasn't seen the evidence, the evidence must not exist.)
Cowan says that my quote from CONTU is ``misleadingly selective,'' and that my ``claim that private modifications are allowed'' is not ``credible.'' In fact, modifications are allowed. (Cowan logic: if there isn't evidence that he's wrong, then he must be right.)
Moen says that Cowan ``furnished a more-complete quotation,'' finding that it ``contradicts'' my summary and that my quote was ``distortively selective.'' In fact, my comments are entirely consistent with the CONTU report. (Moen logic: If Cowan puts the most words in quotes, Cowan must be right.)
Moen says that Cowan ``convincingly disputed'' my summary. And so on ad nauseam. It's rather amazing how tall a tower of stupidity can be built on a foundation of ignorance.
Re:Who uses bind4 anymore department? (Score:4, Informative)
Systrace will likely stop this attack from even being effective.
Chroot'ing means that you give the program access only to an almost empty folder (basic config files).
And Droping to a normal user means that it no longer has root permissions (and so can't even overwrite the few files in the chroot).
Any one of these three security measures should stop this exploit from accomplishing anything. It's practically impossible that all three could be circumvented.
So, no, my DNS server isn't going to be sending out ANYTHING.
Besides, I haven't even implimented user/group filtering with PF yet. That would mean, even if an attacker got around systrace, and the chroot, they would not be able to transmit any data except on the ports I've allowed (e.g. only 53), and I could even set up a stateful rule that would only allow port 53 traffic in response to an outside request...
Computer security has been a complete mess for some time now. It's beginning to look like it may be straightening out (provided you have a good admin that can impliment all of the available security tools).
Re:QPL? (Score:3, Informative)
How many root nameservers run DJBDNS?
It's actually pretty appalling that all 13 root nameservers run BIND8 -- that any of them do, actually, but particularly that they all do. Fortunately, it looks as if the RIPE.NET root nameserver will switch to the new, and very promising (for authoritative nameservice only) NSD package, which is BSD-licensed.
No AXFR w/TSIG support yet, but it's under development.
Rick Moen
rick@linuxmafia.com