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.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
Does TinyDNS support internal and external views? By this I mean, can it return a different IP for the host "foo.my.com" based on what subnet a client is connecting from (e.g., return 192.168.10.11 for all clients in 192.168.* and return 4.3.17.45 for all clients outside of that)? If so, I will switch. If not, I need that function of Bind 9.
MORTAR COMBAT!
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
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
Come on, Bind 9 has been out for some time, so don't flip out!
It was pointed out on the nylug-talk list that the advisory doesn't seem to include any info about whether nominum, paul vixie, or the ISC was notified about the bug.
Does anyone know if ISS did the right thing, or are they being big doo-doo-heads?
-Peter
== Just my opinion(s)
[] 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
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.
The potential for a passive worm is actually fairly high, given that the exploit needs to come in response to a DNS query: The worm infects a DNS server, and waits for queries. It responds to those queries from other DNS servers by attempting to infect them.
The nasty parts: Enough people dual-use their DNS servers (serving as both authoritative master for outside and for their own lookups) that you could get lots of authoritative masters. It also does NOT scan.
It could be made even stealtier if the exploit, on failure, would still function. On success, it of course functions normally. This might be harder, but, if so, it would be really REALLY hard to detect such a worm.
It would take a bit of writing to get right, so there is a good window in which to patch your machines. So patch SOON.
Test your net with Netalyzr
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.
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.
No, it's secure because no one has ever found a flaw in tinydns. He has a *cash* reward for anyone who can prove that it is flawed. No one has taken then money, in several years of it being offered.
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)
For me, it is not really an option to use a tinydns or any other DNS solution other than BIND. Upgrading to BIND9 is not really an option for me either. I work for a large multinational, and we have a lot of UNIX servers (Sun, IBM, and HP in terms of numbers). I get hardware and software support direct from the manufacturer, and if I install an application, or a version of an application that my vendor does not support, I am on my own. These 24-7 support contracts are important to us in being able to sell our services and maintaining our SLA's and availability targets. Those issues aside, I do not want to have to explain to the PHBs that we cannot get support on a particular problem because the application in question is not supported by Sun, or that IBM only supports version 3.4 and we run version 4.0.
So, it is all well and good if someone out there has the choice to install some other software, but keep in mind that it is not necessarily an option for everyone...
*** Where are we going? And what's with this handbasket?
Thats just like the postfix situation. No one has reported bugs.... however if you look at most of the sendmail "bugs" over the last 5 years, you will find they workaround bugs in standard libraries and operating systems, not the main program code. If you look at the patches to sendmail and see if they have are need and applied to other packages, you will find they were needed but aren't applied. None of the people paying for bug reports will pay for bugs in the OS.
Hey, this guy offers $10,000.00 to anyone who can disprove his *AHEM* theory, and no-one has taken HIS money.
Be wary of any facts that confirm your opinion.
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
BIND - serving remote shells since 1986 ;)
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.
Used to run Bind9, but BIND seems to be suffering from the Microsoft bloat phenomenon. How many megs do you need for serving up DNS?? The BIND 9 decompressed tar file comes out to 2100+ files at 21MB. If I recall the installation process, it took forever to compile and then loaded the system with a bunch of superfluous directories and files. For more complicated installations with more exotic requirements than I have, maybe I can see using BIND9, but for my wimpy little web server that has maybe two or three A records to its name, there's no point, so I use djbdns.
-R
BIND 9 is slower than BIND 8, because it does a more correct job, but it's not significantly slower for most applications. If you are running a root name server, you will have to buy bigger iron. If you are running a corporate nameserver, you probably won't. For home use, BIND 9 will perform nicely on a 486 (I run it on a Soekris board, for example).
BIND 9 is also not bug-for-bug compatible with BIND 8, so there are some things you can do in BIND 8 that are broken, that you can't do in BIND 9. So upgrading can require some rework if you happen to have unwittingly tripped over those bugs.
On the other hand, BIND 9 is a complete, ground-up rewrite of BIND. It works better, is easier to use, and because of the strict practices that were followed in implementation, is much more reliable.
BIND 9 also supports DNSSEC, which isn't yet widely deployed, but is worth checking out.
(I used to work for the ISC, so you might think I'm biased, but I wasn't involved with the ISC BIND project, so it's more that I got to look on while they did it, and was there to see some of the design work they did to make it more reliable, I know the engineers who did it, and I really think they did a great job.)
With all of the security news lately, I am too scared to run Apache, IIS, Exchange, lpr, lprng, mySQL, PostgreSQL, Outlook, Outlook Express, map Netware drives to Win 9x clients, X11, use any program that requires glibc, or use BIND 4 or 8 or any DNS for that matter. My computer sits in a locked closet, lacks input devices, and runs only the OpenBSD kernel and nothing else.
Those who are stuck with BIND 4 for legacy reasons or whatnot are probably best off switching over to a chroot'd configuration - it's all very easy and the functionality is already built in.
You are not alone. This is not normal. None of this is normal.
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.
Clearly that's the way to do it. Every other modern server-based app that needs a database has the database in a separate program and address space. BIND and Sendmail are archaic exceptions to this rule, and look where all the security holes show up.
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.
Sendmail likes to _blame_ things on the OS that are really (at least /usr is /usr be group-readable. (If it were world /usr, wasn't
partly) sendmail's fault. For example, being insecure if
group-readable. That's just silly; there's nothing inherently
insecure about having
writable, that would be something else.) (It was
it? It's the thing you have to change in the filesystem to get
sendmail to be secure on OS X.) IMO there's no excuse for sendmail
to blame that on the OS; in the first place, sendmail should be
secure regardless of the filesystem permissions, and in the second
place if it doesn't need to read such places it should run as a user
with fewer permissions (e.g., with its own group like Apache does).
qmail, for all the complaints you can make about its license, at
least takes responsibility for its own vulnerabilities.
Are weaknesses in the OSes _partially_ responsible for some of those
vulnerabilities? Well, sure, but the weakness is exploited through
sendmail and does not have an impact on competing implementations;
that makes it sendmail's problem in my book, and blaming it on the
OS is just a way of shirking responsibility. Do you report the
vulnerability in the OS? Heck, yes, but you also fix your app to
not be exploitable through it. The sendmail people need to drop the
"don't blame sendmail" attitude and write secure software. I know
it's hard being the leading server software in a particular market,
but when openssl can be exploited because of an issue in certain
kernels, they patch openssl. When the openssl issue causes some
Apache installations to be vulnerable, the Apache people release
an advisory. It shouldn't be about placing blame; it should be
about _fixing the problem_. The sendmail people are more interested
in pointing fingers.
Not that there aren't things you _can't_ work around, that have to
be fixed at the OS level. Keeping unauthorized local users out of
the data on a system without filesystem permissions (e.g., Win98),
for example, is not something that can be fixed by the app, at least
not easily. But at some point a line is crossed where the problem
_should_ be fixed in the app. Especially if it's an app that listens
on ports or otherwise receives data from random entities on the net.
sendmail has a long history of being vulnerable -- way worse than
BIND, right up there with IIS and Outlook. And it's going to
continue to be that way for as long as they keep wanting to blame
their issues on the OS.
Cut that out, or I will ship you to Norilsk in a box.
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).
You say the djbdns "license" is "more restrictive" than Microsoft's "shared source license".
You don't know what you're talking about. Dan Bernstein does not allow you to redistribute FORKS of djbdns. You are very explicitly allowed, in perpetuity, regardless of what Dan says next year, to redistribute djbdns source tarballs with a specific MD5 checksum. Obviously, you are also allowed to publish patches and detailed vulnerability reports. You're simply not allowed to distribute adulterated source code or your own "fixed" binaries.
This is of course a moot point. There has never been a published vulnerability in the qmail or djbdns codebase. qmail is one of the most widely used MTAs on the Internet. The incentive to find vulnerabilities is huge. Bernstein's methodology is correct and his understanding of the Unix secure coding problem is complete.
You say that there hasn't been a djbdns release since last year and offer that as evidence that djbdns is going "stale".
You don't know what you're talking about. There hasn't been a new qmail release in years. qmail remains one of the most popular MTAs on the Internet, contending seriously only with the diminishing Sendmail hegemony and Microsoft's products. There are no new qmail releases because qmail is complete, hasn't had any security problems, and does virtually everything anyone wants an MTA to do. There hasn't been a new djbdns release because djbdns is complete, hasn't had any security problems, and does virtually everything anyone wants a DNS server to do.
Has Bernstein put permission to redistribute any patches against djbdns in writing? If so, then the license becomes roughly equivalent to the Trolltech QPL.
As Prof. Bernstein himself has pointed out, as a matter of copyright law, patches are considered analogous to commentary on the original work, and not as derivative works. Thus, the author of the original work has no claim upon them.
So, with a source-available proprietary software package like djbdns, you can end up with a quasi-free software ecology based around distribution of patches and compile-time modification. Inevitably, those patches end up being very seldom regression-tested against one another. Also, if the base package ever ceases to be maintained, continuing development via patch-distribution alone isn't really very practical. It would rapidly become such a hassle that I'm pretty sure the project would effectively die, at that point.
The fix for that problem is of course licensing that includes a right to fork. But that's possible only if the copyright holder is willing to grant that right, which Prof. Bernstein (for most of his project) is not.
That is not intended as a criticism of Prof. Bernstein (whom I admire for his dogged defence of crypto rights), nor of his software (even though I don't like or use the latter). It's just the facts of copyright law and licensing as I understand them.
Buggy? At least the vulnerability mentioned in the article does not affect most recent version of BIND 9.x.
Indeed. One of the most distressing aspects of Prof. Bernstein's flying squadron of groupies is their characteristic shading of the truth on well-known key issues. One of those issues is the vital distinction between BIND8 and BIND9, which by and large they're fully aware are distinct codebases following a from-scratch rewrite specifically to jettison the inherent unmaintainability of the legacy BIND8 codebase -- but they find it convenient to slur the new codebase with the old one's faults. Another is their characteristic refusal to compare the Qmail MTA against anything other than Sendmail -- when the obvious comparisons are Qmail/Postfix/Courier (all modular designs) and Sendmail/Exim (both monolithic designs where process instances drop privilege according to role). A third is their curious inability to ever say the words "proprietary" or "not open source", instead making excuses, changing the subject, and talking around that point.
(I'll hasten to add that Prof. Bernstein clearly isn't responsible for his acolytes' conduct.)
Rick Moen
rick@linuxmafia.com
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
thank you for actually making all slashdot readers dumber by posting that.
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
Simply calling that a ``DoS attack'' is stretching the truth.
I'm sorry, but what do you think a DoS attack is? The attack mode described would be a classic example, in fact. Whereas, calling it a "security hole" is actively misleading, by omission.
Besides, as you are perfectly well aware, I did not "simply" call it a DoS attack: I stated precisely and concisely what occurred.
The point was to call attention to yet another example of the polemics characteristic of the DJBware camp, and their tendency to shade the truth. In light of which, you have quite a bit of nerve selectively ignoring parts of my accurate characterisation in order to label it "stretching the truth". I'm not surprised, but I am disappointed.
Rick Moen
rick@linuxmafia.com
Afterthought: The right to fork is such a fundamental assumption of the open-source model that it's easy to forget other vital reasons for it, beyond just the code being maintainable after its owner decides to quit. I posted before thinking of those.
When we say something is "open source", we're also implying the right to create derivative works descended from that codebase. E.g., the most important long-term fact about the Berkeley NET2, 4.4BSD, 4.4BSD-Lite, and 4.4BSD-Lite2 releases is that we got 386BSD, and then {Free|Net|Open}BSD from them. Had the U.C. Berkeley Computer Science Research Group used a Bernstein-style no-forking-allowed licence, there would have been none of those things: Their creation would have been illegal.
So, I think if you mull over your assertion that you "don't think that [a right to fork] is necessary for something to be free (as in GNU free)", you'll see that this right actually is absolutely vital and essential to the very concept.
Rick Moen
rick@linuxmafia.com
"The world's most popular DNS package is once again vulnerable."
This is the scariest part of the security mentality. Whenever a flaw is discovered everyone freaks and says 'oh, now I'm vulnerable!' until a patch is distributed and 'Phew! Now I'm safe again."
This is not the right way to look at it. The flaw was there for years, and you were vulnerable to everyone who found it before a whitehat did. What's more, you're *still* vulnerable to every flaw that hasn't yet made it to slashdot's pages, but will in coming months and years.
Choosing a platform that reacts quickly to patch discovered flaws means only that you're safer from attacks from those people who read the same sources you do, and quickly move to exploit the published vulnerabilities before you can patch them.
The fact is that it's rarely known how many people discovered a vulnerability before it was made public, and so if you rely on a system that requires frequent hotfixes, however quickly the vendor may react, you are still succeptable to the countless holes that have already been discovered, but not by the good guys.
The morals of this argument are that it's better to use a system that doesn't have as many holes, to one that patches them 'instantly,' and that unless another vulnerability is never discovered in your platform, you're vulnerable to attack today, and always have been.
Kevin Fox
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