Slashdot Mirror
Vixie And Others On Members-Only BIND Info
Pac writes: "ISC suggestion of a new 'members-only' security information list for BIND has been the topic of the week over the Internet security community. Kurt Seifried has interviewed Paul Vixie, head of ISC, about the announcement for SecurityPortal. The article includes some (not very suporting) comments from Bugtraq users, including Vincent Danen's (from MandrakeSoft) and Theo de Raadt's (from the OpenBSD project)." If joining the program already in progress, you may want to take this as a chaser to the BIND vulnerabilities and members-only BIND info stories of a few days ago.
Regular users should be aware of such issues, as it makes them more informed consumers. I'd switch ISP's really quickly if I found out my ISP wasn't patching their servers with the latest software, as nefarious people (you know who you are) can do all sorts of nasty thing with a cracked primary DNS server, or a open mail relay, etc.
In a similar vein, bum tires are of iterest primarily to car mechanics and other "car geeks" who will be upgrading the tires, but users of the cars should be aware of the problem as well.
Granted, they don't have to study the matter in the detail a hacker would a Bugtraq memo on the inner workings of a forged BIND exploit, or the chemistry as to why the tires suck... just enough to know that there is a problem and that they probably should contact their admins to see what is being done.
Looks like it's time to replace BIND with djbdns
Funny you should say that - after reading about the BIND priesthood's latest moves I decided to do exactly that. The man's a pain in the rear sometimes but over the years I've learned that his software works, and works well.
djbdns takes an entirely different approach to DNS serving, breaking the problem apart into completely separate components which are addressed by completely separate programs. This takes some getting used to, and it's not always immediately apparent how you can address every esoteric situation that you could with BIND's kitchen-sink approach (mainly because the different programs can't, of course, share port 53). Plus, you have to tread down the slippery slope of DJB replacements for a score of core system services - inetd, init, and so on. But so far I've got DNS servers running in 1/5 the memory footprint, serving queries about 10% faster, from a source that history suggests is all-but-guaranteed to be free of security problems.
Up to now, I hadn't even considered replacing BIND with anything else - just salivating hungrily when new versions came out, in hopes that they might actually run for more than a month or two without an urgent security upgrade. I guess it seemed somehow easier to use the same package everyone else did, if only because experts and books are easy to come by. But now that their long-awaited conclusive answer to the constant plague of security problems is to formally and officially sweep them under the rug, it looked like time to hitch my wagon to a new star. Obviously the underlying problem is not getting solved anytime soon.
"Patriotism is your conviction that this country is superior to all other countries because you were born in it." -- GBS
'man named':
-u user_name
and:
[mark@hubcap mark]$ ps aux | grep namednamed 403 0.0 4.5 2776 1268 ? S 10:09 0:00 named -u named
Bind has been able to run as a non-root user for ages now, certainly over a year.
The other alternative is for everybody who isn't in the little clique to report the bugs to bugtraq and not to the ISC closed group, if most of the bugs go to bugtraq then what is the point if this forum?
----
I hereby inform you that I have NOT been required to provide any decryption keys.
Every single one of us uses BIND on a daily basis. If I were to pull a statistic out of my ass, I'd say 95% of the name servers on the Internet use BIND, including all of the root servers. Every query you do uses BIND, every web site you view uses BIND. Quite simply, BIND is God. It's fascinating but true.
Is there anything he can do? BIND being BSD-licensed, anyone can just slap a GPL on it, call in OpenBind or GnuBind or GnuDNS and that's about it. At the VERY worst, maybe it'd be required to show a message like "this software contains code (c) blahblah". Correct me if I'm wrong, but I'm pretty sure I'm not.
(*sigh*) I wish DJB wouldn't be so anal about his licensing (forced install locations? Sheesh!) I administered qmail, and it rocks. I bet djbdns is just as well-done.
How about everyone just get over it and learn to deal with direct e-mail marketing like adults? I mean, if you guys had your way you'd shoot the postal carrier when he delivered junk mail to your door. Direct e-mail marketing (or spam as you call it I suppose) is on the rise and it isn't going anywhere. We might as well just learn to accept it. If you're really sick of Direct e-mail marketing you could always setup your mail client to discard all mail except those from people on an approved list. Then, no more "spam". All these silly RBL organizations are doing is spinning their wheels anyway. If there was a way to stop direct marketing then I wouldn't be interrupted during dinner by telemarketers or have to sift through 10 lbs of junk mail to get to the 2 letters I'm interested in. The courts have done nothing but support "spam" so why are we even bitching about it? If you're really against it, talk to your congressmen and get it legislated out of existence along with all other forms of direct mail. If you don't want to, then deal with it.
Nope, the analogy is pretty good. It is always much easier to destroy than to create.
Considering vehicle weight, probably better to overinflate slightly rather than underinflate slightly. If the goons in the tire shop know that, then maybe everybody is a tad safer.
Get a clue.
My postman doesn't make me sit there and open all my mail. I don't get deluged with 20-30 pieces of junk every day on paper. What the postman brings isn't going to expand exponentially because the sender pays to have it sent, whereas spam is paid for by ripping people off. My bandwidth is used up when POP3 downloads the junk before I get to see it. Bogus subjects mean sometimes people click on it to read it anyway so just clicking delete still means time wasted.
And yes there is a way to stop telemarketing and I've done it already. And there is a way to stop SPAM and congress doesn't even need to get involved. You just hate it because we cut off so many of your relays.
now we need to go OSS in diesel cars
It there's going to be a major fork, how about we fix that other humongous problem. OpenBIND would certainly be nice if it included OpenNIC and OpenRootServers. ;-) The DNS system has got to be the funniest example of something sustained only by people's unwillingness and laziness to change to something else because what they have is "good enough". We're paying for domain names from companies because no one really bothers to implement a replacement that has gotten widespread enough support.
Suppose you were choosing which of two cars to buy. One model has a history of catastrophic brake problems, and on two recent occasions has been recalled after negative press following bouts of spectacular fatal collisions. (For the sake of argument, assume the two models are comparable in other respects.)
Do you (A) buy the model with dodgy brakes, but install a better airbag and seatbelt and write a will; or (B) buy the other one instead, possibly installing the safety equipment anyway?
From the article:
Features and benefits of "bind-members" status will include:
1. Private access to the CVS pool where bind4, bind8 and bind9 live
It's hard to know for sure, but that seems to be exactly what the article's saying.
But to who? Not my box. Just the DNS server (one would assume, if the ISP was running only the DNS on that server).
I don't think this hack can trace back through my ISP's DNS, find my machine, and hack into it.
- I don't care if they globalize against free speech. All my best free thoughts are done in my head.
Why in the heck do sendmail and BIND keep appearing together in these messages? They were not written by the same person.
maru
I wasn't referring to a remote-root exploit. The recently announced BIND exploits that are the whole topic of discussion are not remote root either (at least not on a properly-configured BIND installation).
maru
If ISC doesn't back off, we're soon gonna have OpenBind.
This is probably the best thing that can happen. Actually, it usually takes one good kick in the teeth for us to realise that what we are using is a lump of crap and we'd better do something about it. I am so fed up of bind. Hopefully, being forced into admitting we have a big problem might give the incentive to fix it. It has been known to happen.
perl -e 'print $i=pack(c5, (41*2), sqrt(7056), (unpack(c,H)-2), oct(115), 10);'
True, the odds of them getting to your personally secured OpenBSD box sitting behind a firewall from the ISP's primary DNS are slim.
However, the amount of damage they could cause on the networking/server side of things is potentially massive, which may hurt you in other ways besides them getting root on your personal machine-- your buisness webpage could be redirected to a porn site, for example.
Occasional security problems?! BIND has a history as a heap of junk. There's no reason at all to put up with that.
First he steered his MAPS project from something
great to something totally awful, and how he's
out to ruin BIND. Oh well. Time for a new
BIND, free of megalomaniacs.
DJB's whole notion of breaking these things up into seperate programs is the unix philosophy. You may argue that the unix philosophy is weird, but "do one thing and do it well" has always been what the UNIX culture stands for, and DJB understands it better than most, I think.
I guess so - this position is 180 degrees from where he used to be, back when he was useful to the community writing code...
-- Ed Carp, N7EKG erc@pobox.com PGP KeyID: 0x0BD32C9B What I'm up to: http://intuitives.mine.nu
For two reasons. First, they're both good examples of the huge, monolithic, everything-but-the-kitchen-sink approach. Secondly, they're both competing with small, secure, engineered-for-security programs written by Dan Bernstein, qmail and djbdns, which is what this thread is about.
Split the code. But he's already made plans for that I bet. This wasn't the first big nasty from Vixie and it won't be the last.
His software *would be* a viable alternative if linux distributions would start caring more about performance and security than they did about branding.
Alas, that will never happen. So, we poor admins are forced to actually compile something. The humanity.
It isn't at all scary. Considering the frustration I've with Amiga Inc's closed source SDK missing minute BUT FUCKING important features WHICH I CAN'T ADD because Tao owns 15% of Amiga and they're closed morons.
I could save Amiga's ass with very little work but I CAN'T. I am not allowed to.
You expect me to deal with that kind of frustration in BIND?
ARE YOU MAD?
I have a question for you.
What's with this need to speculate and guess and pontificate whenever something happens? Whatever happened to principles like only criminals will have the tools to defend themselves?
Admit it. You don't know. And you're making it even worse by guessing at their intentions.
How about asking both sides what they think?
The message on the other side of this sig is false.
So your saying it is only a quantatative difference and not a qualatative difference. "You could act like not knowing the latest hole in BIND is more dangerous than driving an asbestos-insulated Yugo without seatbelts at 115 MPH through L.A. during rush hour while smoking unfiltered Camels, but it's not." Could you please clarify what you were tring to say?
Numbers 31:17,18 Now kill all the boys. And kill every woman who has slept with a man,but save for yourselves every virg
Very good point. I think that there are other good reasons to fork or have competing implimentations, but this is an excellent one.
We don't, however, have to go all the way back to the potato famine to see the damage that this sort of heterogeneous community has. Take a look at the damage that the infamous Morris Worm wreaked. It only knew how to exploit sendmail and either ftpd or fingerd on Suns and VAXes....
To lots of server admins, and other people concerned with security issues, this is not a trivial story and counts as "stuff that matters".
siri
Perhaps some of the larger players, ie. a few certain companies that have had oh so public problems with their dns, could throw some support behind the cause. We can fork until the cows come home but without proper planning and support, in the end we'll be back to square one.
"Having bind run as a non-priviledged user would have greatly minimized the security
.|` Clouds cross the black moonlight,
breach. The very fact that bind doesn't do that leads me to believe that it is insecure by design. "
So why not stick `-u named' on the end of the command?
Chrooting *is* a jolly good idea for all daemons you're going to be running. But bear in mind that you can break out of a chroot jail, even easier still if you're running as root within it. (I've not read so much about it, but look into shared library requirements and that sort of thing.)
Also remember that prior to 2.2.16, any process calling setuid() could return to being running as root by breaking capabilities, anyway.
~Tim
--
~Tim
--
Rushing on down to the circle of the turn
Get it here
Contrast qmail's security history -- with only one, non-compromising DoS vulnerablity -- to sendmail's -- chock full o' root holes -- and you'll see that there is no comparison between the two.
Don't trust anybody's reputation. Read the code. Compare qmail's code to sendmail's. Compare djbdns's code to BIND's. No comparision. Say what you will about the man, but djb codes with a paranoia that few can match.If security matters to you, read the code.
Easy, automatic testing for Perl.
Um, yes it is. If this consortium produces a fix, they don't have to release it in binary form, and therefore don't have to release it in source form either. All the GPL says is that if you release binaries, you also have to give the source to anyone who has the binaries if they ask for it.
You have good reason to be nervous. Even a hint of supression and you would be safer if the exploits were published before the fixes!
With respect to monoculture, there are at least four DNS server implementations out there - BIND 4/8, BIND 9, djbdns and Microsoft. If you're afraid of the BIND monoculture and you're running BIND 8, you do have alternatives. Personally I run BIND 9 on my alpha, which takes care of the monoculture issue for me. :')
With respect to questioning Paul's motivation, please think carefully. Paul and the ISC are supporting BIND 8, even though we have a code base that's much more supportable in BIND 9, because he knows that not everybody can just up and switch to BIND 9 right away.
It's a lot of extra trouble to support BIND 8. Nobody wants to do it. Nobody wants to pay for it. You heard from the guy at Mandrake - he's offended that anybody would even suggest that they could contribute monetarily to the maintenance of BIND 8. Despite this, when problems crop up with BIND 8, we do our best to fix them in a timely manner, with a very good track record so far.
I don't know if the proposed revenue stream will amount to enough to hire an engineer, but maybe it will. As far as I can see it (and I'm not an insider on this because I'm a DHCP hacker, not a BIND hacker), the proposal doesn't change when problems will be announced to the public. Paul was quoted in this article as saying that the ISC was interacting with vendors through a private channel (CERT) about this bug - just not a very handy private channel.
Even so, the CERT advisory andthe fixed versions of BIND 4 and 8 came out before the BugTraq advisory. You can argue about whether or not the ISC did the right thing in not announcing the exploit on BugTraq before there was a fix, but what the ISC did looks pretty ethical to me, and it looks like the Open Source community got a pretty good deal.
Naturally I'm a bit biased, but frankly after all the work I put into ISC software, and all the work I know Paul puts into it, not to mention the work all the other ISC people do, it's kind of sad to see how willing folks are to accept the idea that we're rotten incompetent villains out to make a fast buck at the expense of our peers.
Banks used to hide their vaults from the public. You had to be have a safe deposit box or be an employee to even see the vault. In new bank construction, the vault is usually visible to the street through the glass doors or storefront.
People planning serious physical security always assume that the attacker has complete knowledge of the defense and its weaknesses. For example, I once read a book by the Nuclear Regulatory Commission which specifies physical security barriers for nuclear plants. Each type of barrier (for example a 10" thick poured concrete wall) has a rating in minutes. This is the number of minutes to penetrate it with the best technique, whether that technique is explosive, gas-powered saw, cutting torch or whatever. This lets them plan security rationally and not have their plan disintegrate because some piece of info was leaked.
And simply making assumptions without reading any documentation isn't a "stupid cop-out"? Of course djbdns supports TCP queries. dnscache (the caching resolver) listens on UDP port 53 and TCP port 53. tinydns, the authoritive nameserver, listens only on port 53, BUT, if you get near the 512 byte limit (which you really shouldn't), you can run axfrdns under tcpserver which will serve queries on TCP port 53.
And the solution is to let the moron's who wrote the fucked up code in the first place, to work on it secret?
The current Slashdot moderation system is made by gay communists!
Yes, it is better to assume full knowledge when designing security systems, but that doesn't mean that we should do our damndest to make sure as many people as possible have full knowledge. This is what public disclosure does. If I find a security flaw in a peice of software, publicize it, and some jackass uses it to crack a server or something, I am partially responsible, aren't I. If a parent leaves a loaded gun on a table and their young child kills himself or his sister, then the parent is certianly legaly responsible. How is this different?
Numbers 31:17,18 Now kill all the boys. And kill every woman who has slept with a man,but save for yourselves every virg
Open source security doesnt claim to prevent bugs or holes, it claims to get them fixed faster. Just like whitehat hackers. Lets see: Privateonly list reveals bug in bind. people on the list fix servers they own, maintain. Prepare for a fix in the next release.
The millions of sites not on the list still have the hole, dont ever upgrade bind because there is no bug known...and stay that way for a while...meanwhile they are experiencing unexplained bugs and attacks.
OR:
Hole is found and documented, everyone can access this info, sysadmins fix their servers in fear, some sites go down because the admins arent doing their job.
The port is bound after starting threads because it can't be bound until after the config file is read, since the config file specifies the ports to listen on. The config file is read after threads are started for several reasons, not the least of which is that it's also read with threads active in the reload case.
With bind 9 on linux, a chroot jail cannot be broken out of using those steps, since the CAP_SYS_CHROOT capability is dropped.
If you want setuid on a 2.4 kernel, compile with --disable-threads.
LinuxThreads aren't different, but under 2.4, capabilities can be retained across setuid(). So, named can call setuid() early (that is, before threads start), while retaining the ability to later bind port 53.
Apparently it's not working. I realize that, as the primary unix nameserver, it's very dangerous when a new bug comes out in bind. Millions of sites probably run bind, and they're all vulnerable to the latest bugs. This is obviously bad.
But doesn't going to this private-group model for security information show that the open source security model really doesn't work for important, widely used applications?
Ben Schumin :-)
I used up all my sick days, so I'm calling in dead.
You are all *completely* missing the point.
EVERYTHING THAT IS CURRENTLY PUBLIC WILL REMAIN PUBLIC AND WILL BE RELEASED ON THE SAME SCHEDULE THAT IT ALWAYS HAS.
Certain information which is private *NOW* will be made available to people who have a plausible, legitimate, reason to want to have it *even sooner*. Access to the CVS tree, stuff like that. Stuff that *no one* gets right now on any kind of formal basis.
No one is talking about not releasing bug fixes in source, or not releasing bug announcements *exactly* when they are released now.
They have *always* waited, whenever possible, until a fix is known before releasing a bug discovered through auditing.
There's nothing, at all, worth complaining about here. This isn't "security through obscurity". This is "let's make the internal discussion about how to handle a bug a bit broader so that vendors who need to be involved early can do so".
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
The "free" in free software refers to freedom, not free of charge. You are free to copy the software. That's free. If you want high-quality, responsive support (i.e., not what you get on the free mailing list), you may be asked to pay for it. Does RedHat ship you CDs for free? No, but they do let you download the software for free. Same deal with ISC, only the thing for which we charge may turn out to be different. *shrug*
The operative question is: Is this a good thing? I think the track record (ssh/openssh, RSA/PGP/GPG, GIF/JPG/PNG, UNIX/BSD/Linux, etc, etc) shows that the answer will eventually be yes.
He is no more fucking ORBS than Linus is fucking Bill.
Producing a superior product is not called "fucking", it's called "innovating".
...now, if we could just teach the USPTO the difference between "innovating" and "fucking", the world might actually be a nice place.
--
Do daemons dream of electric sleep()?
djb doesn't release his work under a proper opensource license, so most distributions want nothing to do with his software. Thus djbdns is not a viable alternative.
It may make it a tricky alternative for distributors (who have to supply the original plus patches rather than a modified original), but that doesn't mean it's not a fine alternative for savvy admins whose needs it otherwise meets.
Qmail is saddled with the same restrictions and is used by many of the busiest mail sites on the net (Hotmail, Critical Path, Yahoo, the spam-magnet server in my house, etc.). Surely there's some hint of viability in there.
"Patriotism is your conviction that this country is superior to all other countries because you were born in it." -- GBS
Replacing BIND involves creating a program that properly implements a number of well defined protocols. Replacing the Internic involves convincing everyone running DNS on the Internet to switch to a different set of root name servers. Both tasks are technically feasible, but one of those tasks is extremely unlikely due to political reasons.
On the other hand, if you could convince Redhat, SuSE, Mandrake, Sun, and the *BSD distributions to ship with your new root nameservers in their default named cache, you would probably be most of the way to highjacking DNS since many admins wouldn't be bothered to notice the difference (and the remainder might be willing to give you the benefit of the doubt if your reliability and response time was as good as Internic's). Convincing all those vendors might be a little tough, but it's more likely than convincing hundreds of thousands of sysadmins.
Laissez lire, et laissez danser; ces deux amusements ne feront jamais de mal au monde. - Voltaire
...but Im tired of updating BIND every once in a while. If a fork would produce a much higher quality software to do the job, then fork the damm think.
I think is way too much responsibility for the ISC to do such an important piece of software for the Internet and to be by far the most used.
All that Im trying to say is that there should be others open-source/GPL choices of software for this task.
irish potato famine?
saying there was not enough food grown in ireland to feed the population during the "potato" famine(s) is like saying the armenians committed mass suicide in 1918.
$ ls -ld /usr/local/named
/usr/local/named/
drwxr-xr-x 5 named named 4096 Jan 31 17:13
$ ps -ef |grep named
named 577 1 0 Feb02 ? 00:00:54 named -u named
Quoted from the bind9 FAQ:
Q: Why doesn't -u work on Linux 2.2.x?
A: Linux threads do not fully implement the Posix threads (pthreads) standard. In particular, setuid() operates only on the current thread, not the full process. Because of this limitation, BIND 9 cannot use setuid() on Linux as it can on all other supported platforms. setuid() cannot be called before creating threads, since the server does not start listening on reserved ports until after threads have started.
My take on this:
Then why the hell do they do the setuid() call so late in the process? Just do it right after binding the port, but before forking any threads. Why the hell does that port have to be bound after starting threads? It's shared by all threads anyways, so why not bind it early?
> But some people have suggested that it is possible for a process to get out of chroot. Can somebody please elaborate?
If a process still has uid 0, there are several ways to break out of chroot:
- make a subdirectory foo
- chroot into it (without chdir'ing into it...): Current directory is now above root... Indeed, the chroot syscall only changes your process' root, but does not automatically change its current directory.
- repeatedly chdir("..");. This works because chdir only checks whether your current directory is equal to your root, it does not check for the case where it is above the root.
- once arrived at the physical root, chroot("."); and presto, you just broke out of the chroot jail
Even if this hole was patched (AFAIK, it exists in all Unix variants...), it would still be possible to break out of chroot by fiddling with raw devices such as disks andSay no to software patents.
I need source to fix it.
It isn't all like a safe. It's like a tire.
I need a knife to cut a tire. I need Firestone's trade secrets to fix it.
The message on the other side of this sig is false.
Because they're both 1) widely used, and 2) have had remote root exploits.
-russ (webmaster@qmail.org and webmaster@djbdns.com)
Don't piss off The Angry Economist
>just another typical slashdot knee-jerk witchhunt that is completely unfounded. /. (at -1 yet).
Maybe that's why I read
I have no problem with giving the authors a bit of time to fix the problem before making it public, but I know that I would much rather read about a potential problem that experience it first-hand. Keeping bugs and exploits secret doesn't really work very well.
A damn good idea.
Mr. Vixie has been a little vague.
In trying to read his email and interview in the best-possible light I think that his bind-members mailing list proposal may not really be a bad thing for the internet community. We all rely on Bind and we all rely on mostly the same sources of information about vulnerabilities and vulnerability fixes (CERT, bugtraq, ISC-patches for Bind, etc).
I think what Mr. Vixie has said can be read this way:
Some vendors have ISC-derived private code. They want some support for their code from the ISC and they want to discuss fixing their closed-source Bind-derivatives in a closed forum (thus the NDA's and PGP encryption on the mailing list). The bind-members list will become that closed forum. New CERT advisories and ISC's own vulnerability discoveries will still be posted and available in open forums at the same time they are available to the closed forum. However, information that only applys to the closed forum will stay inside the closed forum.
If that "spin" is correct then the closed forum members will be subsidising the ISC's development efforts (on a regular basis) and getting privacy for their money.
I think there aught to be a parallel open forum for the free software Bind derivatives and distributions for posting bug discoveries and bug-fixes.
While Vixie's proposal is not strictly a bad thing we won't know if the closed forum is sticking to their stated mission. I think the real solution is to start development in the spirit of Mr. DeRaadt's comment: re-develop bind into task-oriented, well defined subcomponents. Large "hub" nameservers and root servers will use more components than small local nameservers and caching-only nameservers will use fewer still.
The development of this new nameserver daemon should be under a Free software liscense (GPL(!!)).
Then again, I could be wrong....
I've discussed this with a few admin partners and the BIND problem is something that always takes significant amounts of time to stay on top of. Seems the timing is right for either a code fork, or more effort on alternatives. I don't like the licensing sound of dbj-dns, so I don't think that's the answer. It's not really clear what the license is.
Something that has an application front-end with a database back-end would provide better security and other features. The dbase could be replicated to off-line servers for redundancy in case of faults. This could also be used for load-balancing and backups as well. The front-end for administration could be web-based with a php or perl api for ease of expanding the application. I'd be interested in seeing active development on this project and would definitely contribute. Note that MySQL is GPL, so the potential for this type of thing happening again would be eliminated.
Linux rocks!!! www.dedserius.com
www.dedserius.com
VB != VisualBasic
Since qmail has already had one exploit in its history, why should we believe that the rest of DJB's software is any more secure?
maru
When anyone imitates MS's security tactics (ignore, deny, obviscate and cover up) there is going to be a problem. It saddens me that such an important piece of "Internet software" such as bind is taking this route. I just wish there were some better alternatives taht interoperated with bind. I predict if the "members only" security list and the hog wash that will go with it comes to pass, bind will slowly die as people look for better, smarter software.
"Science is about ego as much as it is about discovery and truth " - I said it, so sue me.
Please do not consider this flame-material, but such a fee-based consortium is not possible under the GPL. Vixie poo-poos the GPL, but as we generally regard closed-BIND as bad, this clearly is a case in favor of GPL'ed source. Thoughts?
To answer your rhetorical question, I don't think anyone believes that djbdns is inherently more secure than qmail (although it is a lot easier to configure qmail in an insecure way, if for no other reason than that it's capable of running programs from .qmail files). I trust both of them a lot more than I'd ever trust BIND, though,
even if that isn't saying much at this point.
Isn't the author of , a with many past security problems?
maru
Curb some of your projection of context.
The message on the other side of this sig is false.
I don't suppose djbdns support Dynamic DNS, DNSSEC, or any of the other goodies that BIND does? I really wish I could switch and try it, but some of us have to at least TRY to deal with the Win2000 Active Directory weenies. Besides, DJB's whole notion of breaking these things up into seperate programs is just weird. To replace BIND I'd need to install at least 5 or 6 of his different programs of which I have no guarentee they'll even perform with the same functionality. It seems like his server doesn't even support TCP queries! Simply throwing up your hands and saying you should never get a response larger than 512 bytes is a stupid cop-out.
This is just a common fallacy. Look at qmail. Its security guarantee has been around coming up on 5 years now and has gone unchallenged. Sendmail has about 47% of the market share, with qmail around 11%...qmail may very well deliver more Internet mail messages than sendmail (sendmail has such a large share because it's the default install on most OS's). Who would you rather trust? The BIND company who can't seem to get things right, or an author who obviously knows what's up based on his other software (not to imply that djbdns cannot stand on its own--it's been around for about a year now)?
In fact, Paul said that they were going to continue to distribute code in the same way they always had - which I take to mean including source that anyone can look at. I doubt there will be much change in the way 99.9% of the community interreacts with Bind and ISC.
Today, what happens is that someone finds a bug, ISC gets told about it, and then they FIX IT IN PUBLIC, while thousands of script kiddies run around and try the exploit on machines that don't even have a patch available yet. Even Microsoft is usally given the opportunity to fix major security bugs prior to them being posted publically on Bugtraq. Why should ISC be any different?
From the bugtraq faq:
Now, assuming that people DO this, where today can ISC discuss and fix the bug in private? I think having a list with only selected individuals on - specifically the ones Vixie mentioned, including the people who maintain bind for the major Open Source Distributions (FreeBSD, Linux, etc.) - where they can prepare fixes prior to CERT releasing the information and (hopefully) prior to it being seen on bugtraq.I'm not sure the reason behind the fees. Perhaps it is to help pay for the additional coordination required for doing this. Perhaps it's just to keep the script kiddies out.
I'm also not sure about the private access to the CVS database. This is the only part of this that concerns me. I can think of several reasons why this might be a good idea. Does anyone know if you can get a hold of the CVS database today?
Not sure what the fsck happened with that previous post, it previewed fine. Was supposed to read:
He isn't the author of [insert the name of any widely used *nix-based software that is 10+ years old] , a [insert application use] with many past security problems?
maru
The current process is that whenever ISC finds out about a security bug in Bind, they don't put out a press release announcing the problem until they have a patch ready, and until the root server and other critical servers have the patch already applied. This makes sense, right? If they put out the press release before they started looking for a fix, then it would be a race to see if ISC could analyze the problem and create a patch before some hax0r reads the press release and brings down the root server.
Now, Vixie doesn't create the patch all by himself. There is an inner circle of people who create the patch and ensure that critical servers are updated with the patch before the press release goes out.
What is new is that ISC wants open up the membership of this inner circle. In other words, the process becomes more open, because more people will be able to join the inner circle, and there will be a public process and public criteria for joining.
If you administer a server running bind, and you aren't a member of the inner circle, then nothing will change for the worse. Announcements of security bugs in bind will continue to be accompanied by a patch that you can immediately download and apply upon learning about the bug. Bind will continue to be open source and free software, as it always has been.
So why the outrage? Do people really want Vixie to publicize bugs before anyone has had a chance to create a patch and fix the root server? Think about it.
I have written a truly remarkable program which this sig is too small to contain.
djb doesn't release his work under a proper opensource license, so most distributions want nothing to do with his software. Thus djbdns is not a viable alternative.
Or I can just run BIND 9.1.0 and not have to worry about whether I'm running the right programs to properly serve DNS queries on the net.
You'll find a real hesitance for distributors to use qmail or djbdns because even if they do find a bug (remotely exploitable or not), the only person who can 'bless' such changes to the code is D.J.B. himself, since his license prohibits binary OR source distribution of modified code. Debian found an unusual way around it via their dpkg system to download the original tar.gz, a diff, and then build the executable at install time, but for most companies this is unacceptable.
I used up all my sick days, so I'm calling in dead.
Paul Vixie has usually preferred to sweep Bind bugs under the table. I filed a set of bugs with him back in 1996 and got a round of personal abuse for my trouble. He has a severe ego issue, given this and several other attacks on people who have dared to question his omnipotence.
--
I run four nameservers, and all four run BIND 8.2.2. I've always been aware of BIND's history of bugs, and BIND's history of having those bugs found and fixed quickly. I don't stay awake at nights worrying that someone is going to break in to my nameservers. However...if I'm not able to see the same information as everybody else, that's going to make me a lot more nervous about running BIND at my business. If this trend keeps up, I'll seriously look in to alternatives. However, it's not like ISC is going to lose money by my changing or anything. What do they care if they irk some random Unix sysadmin?
You, Ser, are a true geek. A very funny Mystery Science Theater version of this most awful novel can be found here
Numbers 31:17,18 Now kill all the boys. And kill every woman who has slept with a man,but save for yourselves every virg
I haven't worked yet with Bind9.
But, I have deployed 8.2.x extensively, and I run Bind as user "named" or "dns" as a matter of course.
If Bind9 can't be run securely on Linux--and I don't think LinuxThreads are materially different in 2.4--then Bind9 may just be where I get off the train.
Matt
Um, no. You made a blanket statement, prepare to die.
/chroot/jail/named
../../../../../ from what I understand.
bind can be configured to run as nonroot in a chrooted jail easily, at least in version 9.1.0.
named -u named -t
gets you started. Other versions I'm not so sure support running as user *blank*. Older versions don't, but the recent rewrite (9.1.0) does.
chroot'ed directories can be escaped by root users doing chroot
--johnny
I agree, this is a very valid point, especially towards DoS-type attacks. However, I'd also like to add multiple different daemons have their own drawbacks, insofar as there is more potential bugs that can hit you. For instance, if you're running two different name servers on the same unprotected subnet, you might well have just doubled your exposure, since it only takes one bug to break your entire subnet wide open. Conversely, (towards your point) more singular cultures also increase the reward factor for would be hackers. In other words, if every site ran its own home brewed name server, the hacker would have to put in effort just to crack that one site. Smaller sites like, say, Edogpoo.com may enjoy a poor cost benefit relationship, from the would-be hacker's perspective.
The bottom line is that there are oppositional forces and tradeoffs, like so many other things in security and in the computing world. One setup is not always the best, it depends greatly on the entirity of the situation.
Bind is obscure and uninteresting? What sort of wannabe nerd are you?
Education is a better safeguard of liberty than a standing army.
Edward Everett (1794 - 1865)
You claim that $500 is insignificant, but it proves that the author is willing to put his money where is mouth is. The ISC isn't doing this with BIND.
In any case, my best assurance about djbdns is the code itself. Take a look. It's absolutely paranoid about security-related issues. The same as qmail. Now take a look at BIND. Which do you feel is more secure?
Easy, automatic testing for Perl.
Speaking of outrageous, how about you people going through my tiny comment history to old stories to mod me down? What's the point? Who's going to read this anyway, except overly dilligent moderators like yourself?
Eye of Argon at +1 LIVES!
I think that the reason he uses such draconian language is that he wants to ensure that any modifications by a programmer will not make djbdns less secure. I think it would be pretty easy for any new code to make his code less secure, if for instance, you were to add a system call using data from a remote machine.
Also if porting to a different machine there may be other architectural/security considerations to keep in mind and trying to force djb's code to fit into that computer architecture may break its security model. That's probably why the license is the way it is.
He does give you the option to send him a request for license specifics if perhaps you might want some leeway but that would be on a case-by-case basis.
"sweet dreams are made of this..."
Zebbers makes it so clear and basic why open source is the right way to go and incompetent administrators should be fired.
now we need to go OSS in diesel cars
But, unfortunately, you WILL have to worry about how secure BIND 9.1.0 *really* is. It's still an ungodly amount of code; djbdns is about 18,000 lines. You laugh at people that say "this new version of RedHat will be much more secure--it HAS to be!", don't you?
I've actually witnessed this before, in the opensrs mailing list.
maru
Excuse me. djbdns is only about 11,720. For the record, BIND 9.1.0 as obtained from ISC has 279,221 lines of code in *.[ch] files.
Djbdns is to BIND what qmail is to sendmail. Not only is it written with security in mind, it even has a security guarantee. A refreshing change of pace.
Easy, automatic testing for Perl.
Ahh, yes. Somebody finally noticed. Unfortunately TCP/IP was not added to UNIX until BSD in the 80's. So we have BSD Sockets and the "Everything is a File" mantra no longer holds.
I believe that Plan9, now known as Inferno, works this way. It was developed in the late 80's/early 90's by the original UNIX people at Bell Labs. Lucent (Bell Labs) has released Plan9 source under their own license, source and binaries can be downloaded here.
Have Fun!
-- Remember: Wherever you go, there you are!
Don't forget Novell DHCP/DNS, it comes with NetWare 5. There are more esoteric DNS servers listed here.
-- Remember: Wherever you go, there you are!
I feel that this whole mailing list looks like an attempt to generate a revenue stream through what boils down to blackmail: "if you do not pay us you will not get timely information about the security holes in BIND."
This will (inevitably) lead to a code split, will be a very good thing: having practically the whole internet run DNS resolver (irrespective of how good it is) is dangerous.
This is what I really don't get. Bind needs root permissions only to get access to port 53. After that, why doesn't it give up root permissions, like Apache? Having bind run as a non-priviledged user would have greatly minimized the security breach. The very fact that bind doesn't do that leads me to believe that it is insecure by design.
My second question is about running bind chroot'ed. I have seen the howto and it looks *very* useful for any daemon, especially bind in light of recent security problems. But some people have suggested that it is possible for a process to get out of chroot. Can somebody please elaborate?
___
___
If you think big enough, you'll never have to do it.
Outside of server admins, what regular user even has to worry about this? Isn't this more a thing for BugTraq than Slashdot?
- I don't care if they globalize against free speech. All my best free thoughts are done in my head.
The phrase security guarantee is inapporpiate since noone can guarantee security. This is a security bug bounty.
And 500$ is an insignifigant amount of money compared to the damage that a DNS bug can cause.
--
Remove the rocks to send email
On the whole, I find that I prefer Slashdot posts to twitter ones because I don't get limited to 140 chars before