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:Escape (Score:5, Funny)
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:2, Insightful)
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 ?
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
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.
More about the right to fork (Score:3, Insightful)
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
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: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:Escape (Score:4, Insightful)
That's assuming you ever find one. qmail's withstood the security guarantee since 1998. djb tends to write fairly good software... Besides, people are allowed to release unofficial patches to djb projects and quite a community has grown up around additional features. See qmail.org [qmail.org] and tinydns.org [tinydns.org].
Oh come on. If something works well and implements the standards, why should you bother to add more gimmicks? "If it ain't broke, don't fix it."
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:Escape (Score:2, Insightful)
There hasn't been a djbdns release since 12-Feb-2001 and the project is bound to go stale sooner or later if djb does not renew his interest.
Maybe it hasn't been updated since Feb 2001 since it's complete and doesn't need any new updates? Is that such an amazing concept?
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.
Wow, you're dumb. (Score:4, Interesting)
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 [cr.yp.to]. 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.
Re:AMEN! (Score:3, Interesting)
Re:AMEN! (Score:5, Interesting)
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.
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:Escape (Score:2)
And I guess... (Score:5, Insightful)
TWW
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.
Re:And I guess... (Score:3, Informative)
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.
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.
tinydns: internal and external views? (Score:4, Interesting)
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]
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
Re:tinydns: internal and external views? (Score:2)
"... specifies that jupiter.heaven.af.mil has address 192.168.1.2 for clients in the 192.168.* network and address 1.2.3.4 for everyone else."
Now, why do you need any of the four words you quote to explain/demonstrate the concept?
Re:tinydns: internal and external views? (Score:2)
For versions 1.04 and above: You may include a client location on each line. The line is ignored for clients outside that location. Client locations are specified by % lines:
%lo:ipprefix
means that IP addresses starting with ipprefix are in location lo. lo is a sequence of one or two ASCII letters. A client is in only one location; longer prefixes override shorter prefixes. For example,
%in:192.168
%ex
+jupiter.heaven.af.mil:192.168.1.2:::in
+jupiter.heaven.af.mil:1.2.3.4:::ex
specifies that jupiter.heaven.af.mil has address 192.168.1.2 for clients in the 192.168.* network and address 1.2.3.4 for everyone else.
"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."
Re:Troll submission (Score:2)
Just to clarify: You do know the meaning of quotation marks, and you are referring to the poster of the original story, right ?
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".
Re:patches already available (Score:2)
Link is a 404. Anyone?
Re:patches already available (Score:2)
Re:patches already available (Score:2)
Considering that according to the BIND history page [isc.org] BIND4 has been out since the 80s and BIND8 since 1997, I'd say this isn't exactly a glowing example of OSS's "quick fixes".
Re:patches already available (Score:3, Insightful)
The problem, if you want to call it that, with OSS is that once you release something broken, you have to hear bug reports about it for the rest of your life. I still occasionally hear from people who are running pre-1.0 snapshots of the ISC DHCP server. That's just how it is in the open source world.
In 2150, some idiot on the Mars colony is going to get hacked by a guy in Plano, TX, because he or she is still running BIND 4 on the Marinaris City web server.
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:patches already available (Score:4, Insightful)
It wasn't long ago that a forged 'trusted' mime type would allow an
Re:patches already available (Score:3, Insightful)
Saying such thing is completly unprofessional. It's like selling the unsinkable ship, the unfailable airplane, the unbreakable firewall, etc. etc. Anybody telling nonsense like that should get an unprofessional stamp on his forehead.
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?
Oh and thats why service packs often introduce new bugs. And thats why some fixes are exclusive. Meaning you can apply fix A or fix B. applying both patches will not work. If you apply fix A you get Bug C. Talk with some _real_ admin of a larger microsoft network, you will hear the tears.
maradns (Score:3, Informative)
Don't slashdot ISC yet (Score:3, Informative)
In other news (Score:5, Funny)
Come on, Bind 9 has been out for some time, so don't flip out! [realultimatepower.net]
Newer major versions often drop features (Score:2, Insightful)
Another vulnerability has been found in Microsoft Windows 98...
I take that comment to imply: "Windows 98 Second Edition is too old to be supported; all users of Windows 98 Second Edition should upgrade to Windows XP Home Edition." The problem with upgrading from one major version of a product to the next just to fix a bug is that newer major versions will often drop useful features that an older version had. For instance, Windows XP Home Edition loses Windows 98's competent support for running proprietary applications designed for MS-DOS. In addition, XP Home loses the ability to run acceptably on a 133 MHz machine with 32 MB of RAM.
Does BIND 9 drop major features or require more hardware for a given level of service vs. BIND 8?
Re:Newer major versions often drop features (Score:2)
Upgrading to BIND 9 (Score:5, Interesting)
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.)
Did ISS tell bind maintainers? (Score:4, Interesting)
Does anyone know if ISS did the right thing, or are they being big doo-doo-heads?
-Peter
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.
Re:Did ISS tell bind maintainers? (Score:2)
BIND 9 was not affected by any of the vulnerabilities described in this advisory.
http://bvlive01.iss.net/issEn/delivery/xforce/a
So what makes you say that there are Bind 9 problems? Mailing lists? Can you provide archive links?
-molo
Re:Did ISS tell bind maintainers? (Score:2)
Not everyone can upgrade to Bind 9 however. (Though they may have to.)
Re:Did ISS tell bind maintainers? (Score:2)
The Unix vendors were not informed until last night.
Re:Did ISS tell bind maintainers? (Score:5, Insightful)
This however appears to be yet another situation where ISS has gone ahead and released an advisory before the vendors have actually had a chance to make patches available to the public.
This is supposed to be a security firm that is trying to assist the public in keeping their boxen secure? If so, I'm really scared of the firms that are out there really trying to do damage.
Re:Did ISS tell bind maintainers? (Score:3, Interesting)
The announcement to the public happened about nine hours later.
The vendors were blindsided by this.
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:Tips (Score:4, Insightful)
DJB has been quite clear on this. DJBDNS has his name on it, his guarantee against remote exploits, and his own petty little rant about where things should be installed, and why they should be the same on different systems. As far as he is concerned, you may NOT distribute binaries unless you guarantee they build exactly like the source would build them on the machine in which they are used.
However, he is also QUITE clear. Source patches are fine. Of any sort. This is not any more the original djbdns package, and his guarantee goes out the window. Debian does this with qmail, for example.
I use djbdns, but I REALLY like free software. WHY? Well, BIND is buggy as hell. It is probably the worst possible server software ever written with respect to remote exploits. And, even after the BIND 8 rewrite, it is still buggy as hell. It is also a pain in the ass to configure.
In contrast, djbdns is pretty easy to configure and install. I installed it exactly once per machine (mostly caching servers for local machines only, but also domain servers). It never stopped working. EVER. It never needed restarting. It never needed attention. I sometimes forget it is even running. There has never been an exploit.
So I ask you - if something works like this, why do you need to be able to redistribute anything more than patches? You install the dern thing once and it just keeps going like the Energizer bunny.
So, go ahead, laugh if you want. Install buggy BIND, or some other DNS package. DJBDNS keeps my machines working, free from exploits of dns origin, and it never breaks down or needs attention. And if it ever does, I still have the source and permission to alter it for my own use, and to distribute patches that alter it to others.
That pretty much covers the freedoms I want from my DNS software. Granted, it would be cooler yet if distros could package it and distribute as THEY see fit (placing the trust in the distro and not in DJB), but DJB is kinda quirky, so I live with the next best thing.
Re:QPL? (Score:3, Insightful)
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 [linuxmafia.com]. 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 [linuxmafia.com] 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
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: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
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:QPL? (Score:4, Interesting)
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
Re:Welcome to System Administration 101 (Score:2)
Re:Tips (Score:4, Insightful)
You shouldn't trust the software because of the cash guarantee. You should trust it because it is secure.
Some people will audit the software in hopes of claiming the reward, either for the monetary or ego value. It also means that the author has faith in his software. How many other people will put a cash guarantee behind their code? Dan doesn't have any commercial reasons to offer this guarantee. He does it because he knows his code is secure. Why won't the BIND authors guarantee their code? Because they know that they can't.
Look at it from another perspective. How many people here dislike Dan for one reason or another? How many of those people would love to find a hole in his software to discredit him? How many of those people have found one?
djbdns is secure in the same way that qmail is secure. Read the code for yourself. You will see how different it is from other software. It is quite easy to see how Dan can guarantee that it is secure.
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.
Re:Or you could use bind 9... (Score:3, Insightful)
Re:Or you could use bind 9... (Score:3, Interesting)
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.
What, like supervise from daemontools [cr.yp.to]?
Nah. It'll never work.
Re:Or you could use bind 9... (Score:3, Insightful)
Is it just me, or does the RFC look like it was documenting BIND's implementation, rather than defining a standard which BIND then implemented?
Passive Worm Potential... PATCH NOW (Score:5, Insightful)
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.
Strawman worms (Score:2)
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.
Re:Not So Strawman Worms (Score:2)
As for kiddiots, it only takes one to share his code. (Open Source hax0r tools, must be a good thing right? :^)
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:BIND9 (Score:5, Interesting)
F is a virtual server made up of multiple systems and runs ISC BIND 8.3.3 as its DNS server. [isc.org]
Re:BIND9 (Score:3, Insightful)
With redundant servers running different software, the chance of a single attack taking them all down is minimized.
/. 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.
Who uses bind4 anymore department? (Score:5, Informative)
and read this [sigmasoft.com] for why
Re:Who uses bind4 anymore department? (Score:4, Interesting)
OpenBSD severely audited their BIND 4 code-base and it is very secure. This can be ascertained by looking at their errata pages [openbsd.org] and looking for patches to BIND. There aren't very many at all in the more recent versions.
Sure it's BIND 4, but it's solid and stable, like DNS is supposed to be.
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).
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).
What if you can't use (fill_in_the_blank)? (Score:5, Insightful)
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...
Re:What if you can't use (fill_in_the_blank)? (Score:3, Insightful)
Re:What if you can't use (fill_in_the_blank)? (Score:2)
Bind 9.2.1 (Score:2, Insightful)
BIND (Score:4, Funny)
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
Re:Why I LOVE Red Hat Network (Score:2)
every night at 4am, my debs are updated. and yes I did remove the -d (download only, no install) flag, so it does real updates nightly.
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."
Bind9 (Score:3, Interesting)
I'm scared (Score:5, Funny)
Re:I'm scared (Score:5, Funny)
Cut the power cord and fill the closet with cement.
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:I like MyDNS (Score:2)
Store all of your DNS information in a MySQL db, use the db to make updates, then have a silly shell/C/C++/Java/Perl/PHP script generate the DNS files for you
Please poke holes in my solution
Cheers!
Re:I like MyDNS (Score:3, Insightful)
Who needs DNS? (Score:2, Funny)
66.35.250.150 slashdot
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:Shameless plug time (Score:3, Informative)
- djbdns: no reported vulnerabilities
Hurrah to people who know how to write software properly.Always vulnerable, and probably still is. (Score:3, Interesting)
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.
Re:Tinydns is a pain in the ass to install (Score:3, Interesting)
Re:Tinydns is a pain in the ass to install (Score:5, Funny)
Re:Tinydns is a pain in the ass to install (Score:4, Funny)
Re:Tinydns is a pain in the ass to install (Score:2)
There's a difference between secure and presumed secure.
Re: (Score:3, Interesting)