Slashdot Mirror
Bind 4 and 8 Vulnerabilities
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 your binds, use djbdns.
> Does TinyDNS support internal and external views?
Yes. This page shows you how http://cr.yp.to/djbdns/tinydns-data.html
Slashdot? Oh, I just read it for the articles.
Alternatively, you could update to the latest version of BIND.
From the advisory:
"BIND 9 was not affected by any of the vulnerabilities described in this advisory."
linx pro has more information on the exploit, including patches to fix it.
Does MS fix their vulnerabilities that fast? Judging by the number of klez variants in my inbox, I'd say "no".
This is why I run MaraDNS.
:wq
> ...that's why I run Bind 9 and keep it updated.
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.
Slashdot? Oh, I just read it for the articles.
http://www.isc.org/products/BIND does NOT have the updated versions (4.9.11, 8.2.7, 8.3.4) that addresses these security issues posted yet (as of 1:16 CST). Perhaps slashdot should update the story once the tarballs become available.
-----BEGIN GEEK CODE BLOCK----- Version: 3.12 GIT d? s: a-- C++++ UL++++ P++ L+++ E- W++ N o-- K- w--- O- M+ V PS+ P
[] Most smaller networks don't need a large (and dare I say buggy) installation of BIND.
[] May I suggest djbdns 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 , 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".
If you celebrate Xmas, befriend me (538
Not really a good argument though (if I understand you right). If it's the system libraries and precompiled binaries you're worried about having BIND4/8 "cancer", then it doesn't matter *what* you do - BIND9, TinyDNS, MaraDNS, DJBDNS. That cruft will still be in there, until you recompile everything without said base libs.
It's not surprising that bind 4 and 8 have the same vulnerabilities - they're based on the same code base, after all. Bind 9 was 100% rewritten, is modular, and actually *checks its inputs*, avoiding buffer overruns and such.
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.
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.
ISS did not inform any of the Unix vendors.
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.
"Trademarks are the heraldry of the new feudalism."
Just old versions of bind,
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.
This is not very valid, since this is an exploit to attack DNS *SERVERS*. Not clients with the shared libs. Besides to attack a client, they first need to get you to go to some compromised DNS server, with an application utilizing the bad resolver libs.
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.
Zapman
Answer: OpenBSD See subsection 6.8.3.1
and read this for why
ZERO ZERO ONE ZERO ONE ZERO ONE ONE! Just brushing up for my next big invention: Ethernet over Voice (EoV)
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
== Just my opinion(s)
Two of the attacks are DoS: You crash the server, end of story. One, the buffer overflow, can potentially execute code.
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.
Test your net with Netalyzr
Knowing that this might be a vulnerability issue, I immediately logged into my main servers and typed, in each, "up2date -du --tmpdir=/home/tmpdir".
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 have no problem with your religion until you decide it's reason to deprive others of the truth.
I like MyDNS - http://mydns.bboy.net/ - serves records directly from a MySQL database, and easy to set up and manage.
;)
0.9.5 (development copy at http://mydns.bboy.net/beta/) also supports PostgreSQL.
Of course, I am biased.
You still get the same effective service without nearly as much risk of random idiots exploiting buffer overflows.
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.
The rest of your "arguments" I will not go into because they rely on flawed assumptions.
I was running tinydns on my home computers and the servers I maintain at work, but I was getting frustrated with the locations of the files and the use of non standards services. Note that this is my opinion and I understand that other people may want to continue using it.
/package /command /service /etc/dnscachex /var/spool/djbdns /var/spool/mail/dnsc* /etc/dnsroots.global
/etc/inittab
/usr/local/bin
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
-- Martial MICHEL
Another option, if one does not need recursive caching is posadis. There is also pdnsd, which only provides recursive DNS service.
Security history of various DNS servers:
The secret to enjoying Slashdot is to realize that it should not be taken too seriously.
ISS and ISC worked together on this. ISS found the
vulns, ISC worked with the vendors, and both of us
worked with CERT and coordinated the announcements.
Paul Vixie
Chairman, ISC
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).
He doesn't need to. djbdns doesn't have a license and doesn't need one: http://cr.yp.to/softwarelaw.html
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) 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
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 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. 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
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