Slashdot Mirror
BIND Security Info For "Members Only"?
achurch writes: "Paul Vixie has posted a message to bind-announce suggesting the formation of a "members-only" security information list for BIND, the DNS server used on most Internet systems. Membership would be limited to root/TLD nameserver operators, software vendors using BIND, and 'other qualified parties,' and members would have to sign 'strong nondisclosure agreements.'" I'm not sure how I feel about this, but I'm sure a lot of readers do.
A lot of readers are sure how you feel about this?
His comment:
I write C++ code daily.
Is particularly suspect as a daily C++ writer would know to use the STL and thus remove all (not most, all) possibility of the programmer f'ing up a bounded array.
C, I'm with you on. It's a lot harder to control (though it's a simpler language too, so maybe the two things are a wash)
C++. You can easily contain buffers overflows.
--
I hope your not speaking from a security perspective. BIND is notorious for security holes. For many including myself, this was the proverbial straw that broke the camels back. While it is true that BIND 9 was completely rewritten many believe this will not alleviate the security issues that have plagued BIND in the past.
"Has the djbdns code been audited?"
Well, he does offer a $500 security guarantee. Something no one has claimed as of yet. Djbns was designed from the ground up with security in mind. Djbns has to date proven to be secure. I'm not ingorant enough to claim that it's uncrackable but so far it's record speaks pretty highly. Something BIND can't do.
"Has it been tested in a large scale comercial environment?"
From the FAQ: "How fast is tinydns? Can it handle a huge number of incoming queries?
Answer: One site reported receiving 500 queries per second per server at peak times for data from a 350-megabyte data.cdb. The tinydns process handled about 7000 queries per second of CPU time. The CPU was a Pentium III-550.
This example, and lab tests, suggest that tinydns can easily handle the .com server load. However, I don't have enough data on the distribution of .com queries to carry out a realistic experiment."
Maybe you shouldn't be so quick to dismiss a product until you actually take the time to look at it.
LiNT
BTW, first?
--
I'm not sure how I feel about this, but I'm sure a lot of readers do.
Wow, that is Slashdot in a nutshell, isn't it?
Use djbsdns (from the author of qmail) if you want a secure DNS server. http://cr.yp.to/djbdns.html
Problem is that what will *really* happen is that it will make 'good guys' less aware of the problems than 'bad guys'. For two reasons. First of all what if a bad guy discover the exploit himself at the same time of few days earlier? Then the longer the issue is not disclosed the more time he has to use it. The second is that on any member list with more than two subscribers there will always be leaks no matter what NDA you sign (and i also bet bad guys will tear teir ass to get subscribed to that list and will be subscribed), and the leak will certainly give advantage to bad guys.
So problems should be disclosed as soon as possible, because this is the only efficient way to notify the 'good guys', and even if no fix is available yet knowing about the problem will let people take *some* measures such as monitoring their systems more closely knowing where the attack may come from.
STO is like communism - it may look good in theory but it's not gonna work in the real life.
dixi.
...remember good 'ol times when IP used to mean Internet Protocol....
I have just finished reading Secrets and Lies. This book talks about how security problems used to be handled through an organization that would keep the problems from the public until the manufacturer created a patch. The upshot was that manufacturers often did not take the problem seriously. The book also talks about how software and hardware manufactures have no significant liabilities for security faults. This leads to a bad situation in which the only tool the cosumer can use to effect a fix is the publicity attack.
Additionally, by limiting the distribution of information, one is implicitly limiting the amount of brainpower available to solve the problem. One cannot assume that all of these qualified security experts are going to belong to every closed list. Although open sourcing the code does allow such people the opportunity to look at the code, hiding a problem may not make best use of the available resources.
Having a secure mailing list for product security defect does not make the product more secure. Have a closed mailing list does not make the loss of personal data any less harmful. A closed list of security defects merely allows security products manufacturers to exaggerate the security of the product to an uneducated populous.
If you don't like DJB's attitude, then don't invite him to your dinner party. What does that have to do with the quality of his code?
Personally, given sendmail and BIND's history of sprouting remote-root holes, I rather like the idea of an MTA and a name server that were written by someone who's paranoid.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
The point of full disclosure is that the kiddies already talk to each other a lot, and schmooze with the actual skillful people - the ones that make the "exploit in a box" packages. Not talking openly and clearly, including an exploit so you can verify if your system is indeed secure or vulnerable, just means that the wite hats are hobbled - the black hats will still operate just fine.
With regards to the page on the namedroppers list, I'm sorry to disappoint you, but you've just encountered the power of selective reporting. What DJB is describing is most likely the normal operation of a moderated mailing list, as seen from the point of view of a certifiable paranoid.
I've observed how DJB behaves on mailing lists and on Usenet, and I'm willing to bet that if you were moderating a mailing list with him on it, you'd be deleting a significant number of his posts too. He tries to make every forum into a self-aggrandizing soapbox on which to berate the slightest shortcoming in any competing program.
He has the attitude of a zealot - to DJB it's impossible to even imagine that someone might have a different opinion to his own, therefore anyone who disagrees with him is being dishonest. He's on record on separate occasions as repeatedly labeling Weitse Venema (author of tcp wrappers) and Paul Vixie (ISC lead) frauds just because they don't agree with his interpretations of how software should work.
Bernstein writes good software. qmail rocks, and I'm sure djbdns is good too. He also, however, has the worst interpersonal skills I've ever seen on the Internet. I know people who refuse to use qmail, even though they know it's the best MTA for their purposes, purely because its author is such a wanker.
Hands up who remembers DJB's encounter with a.s.r?
Charles Miller
--
The more I learn about the Internet, the more amazed I am that it works at all.
DJB's code may be secure, but it's a pain in the arse to administer. And that in itself is a security risk waiting to blow.
As most of us know, "Security isn't a thing; it is a process" [Schneier]. Administration is a very critical link in security... as critical as the code, if not more so. When administrative procedures and tools are clear and easy to use, fewer mistakes happen. Turn that around and you get more mistakes that can lead to security exposures, even for very experienced and security conscious administrators.
I switched from Sendmail to Qmail over a years ago. While I didn't regret it, I did experience difficulties in administering it. While I got some help, I also got a lot of "read the source" responses. Those responses were cop-outs. Even though I have 19 years C coding experience, I found DJB's code hard to read, and his organization non-obvious. And there were no comments to explain it. The source code was essentially useless as a resource for administering Qmail.
I looked into changing again, and studied Exim and Postfix. I decided to go with Postfix for some reasons not really related to any problems I found in Exim. I certainly do not regret this change. It is much easier to administer than Qmail. And unlike the Qmail community, I haven't yet run into anyone in the Postfix community that cops an attitude when there is a disagreement.
I am aware of DJB's security concerns about Postfix. But I consider the tradeoff to shed the security problems of administration difficulties to be worth making the move over to Postfix.
This is why I'll be reluctant to immediately move to DJBDNS, though I can certainly say I am tempted to give it a try.
now we need to go OSS in diesel cars
People like Paul Vixie should know better than to use functions like sprintf() to construct messages. Why are these problems happening over and over? And what other problems will the code have that isn't necessarily a security issue, but can cause problems? I find BIND does a lot of bizarre and strange things at times for no apparent (or logged) good reason. I am more and more untrusting of Paul's coding practices, and even his system design.
now we need to go OSS in diesel cars
It's true that exposing security problems gets them fixed much more quickly. However, there's a downside. While the holes keep getting plugged, the situation is the same at any given time:
anyone can look at the advisory reports and find the latest exploit, which will likely work in most places they care to try it.
This step by bind is a good idea - it dampens the effect of that downside, but the source is still out there for people to see and fix. It's not perfect, but the preceding scenario certainly isn't perfect either.
Vidi, Vici, Veni
How stupid of us! All we have to do is get system crackers to sign NDA's.. man.. and here I am sweating my ass off every day to secure my systems, when a piece of paper will do the trick.
Actually, maybe I should just put a banner on my systems which is like "click-thru NDA".. so just by looking at it they have to follow it. Yeah.. Where's my patent lawyer?
I'm sure this has all been mentioned before.
;) because he's had a hand in many crucial UNIX goodies. As far as a NDA'ed discussion group, I think that this would help kill off a lot of skript kiddies from taking down major servers and causing havoc etc etc. Since this BIND bug(s) wasn't exploited before now, it's safe to assume that if a small group had found it, and patched up all the root servers (VERY IMPORTANT!) and prepared patches for major distributions of BIND *BEFORE* telling all the skript kiddies, then a patch would hit the internet before anyone knew there was a problem and there wouldn't be widespread panic, sysadmin suicides, etc. I'm not for 'security through obscurity', but this is different. These are the daemons that RUN the entire internet -- there is a difference in an apache bug and a BIND bug -- apache bug, some websites come down. Email stays alive, etc. But when BIND gets hit like this, especially of this magnitude, then you are really starting to crack the machines that run the most important services on the internet. It only makes sense to fix these bugs before telling kiddies how to exploit them.
This does make a world of sense. Paul Vixie is a very, VERY good man -- without him, most of you k-rad 3l33t l1nux users would still be poking away at your Windows machines (much like many of you still should be
I heard one time at a conference that if all the root name servers went down, at the same time (or close to the same time) then the internet would go dark within 48 hours. Although I don't belive this, I do know that if someone was able to hit the root-servers.net machines hard enough, and almost simultaneously, then we would have a problem.
A big problem.
-- jason
I'm a big fan of full disclosure of security issues, but this isn't an alltogether bad idea. If only because of the criticallity of BIND. If we could provide TLD admins with a little (note a little) warning before exploits were announced it would greatly lessen the chance of a script kiddie doing serious damage. However, the information must be then made public, so other administrators can stay informed. I would support giving TLD admins a head start. I would not support giving them an opportunity to try to rely on security through obscurity.
i can understand why they would want to close the list of announcements of security flaws - it would make sense in terms of protecting their users from people who would take the information and abuse it.
but what's the point in making it cost money? Paul Vixie states "Recent events have very clearly shown that there is a need for a fee-based membership forum" but there's no description of said events, or explanation of any sort. haven't the vendors and name server operators already invested enough in BIND, without making the security information cost more?
can someone else explain the purpose of the fee to me?
This whole idea rests upon the assumption that an elite group can actually keep newly-discovered holes a secret. If I were an author of cracking tools, the first thing I'd do is go after the weakest member of the "elite" group, root his machines, backdoor his email accounts, and enjoy my new-found live feed of fresh security holes that I'm free to exploit because nobody else knows they even exist.
--
314-15-9265
I'm on the bind-users mailing list, and here are some of my comments:
Date: Wed, 31 Jan 2001 20:39:35 -0500 (EST)
From: Jeffrey C. Albro
To: bind-users@isc.org
Subject: Re: PRE-ANNOUNCEMENT: BIND-Members Forum
On Wed, 31 Jan 2001, Cricket Liu wrote:
> > This is not an open source but a full/partial disclosure issue.
>
> No, it's not. No one is arguing that the vulnerabilities shouldn't
> be disclosed and disclosed fully. The question is when.
I agree. However, the "when" part needs to be laid out MUCH more
clearly. If a vulnerability is found on the first of the month, and the
main bind tree is patched by the seventh of the month, how long do you
wait for vendors to patch their (assuming they have forked to some
extent) version? To the 14th of the month? How long will a viable fix of
the main source tree be held in secret?
> Surely you can understand the need to patch critical pieces of
> infrastructure such as the root, gTLD and ccTLD name servers
> and to prepare patched binaries of BIND for various operating
> systems before the vulnerability becomes widely known.
Of course. But how long do you give downstream developers? Do you give
them N days, and when N+1 appears will the forum embarrass paying members
of your group? If everyone signs an NDA, no-one can squeal. Can a time
limit be put on the NDAs?
I believe this idea can help solve security problems faster, with less
advertisement of the exploit, but steps need to be taken to make sure that
is actually what happens.
How is the conflict of interest solved?
-Jeff
>
> cricket
>
>
>
I think Bruce Perens said it best -- "Security-Through-Obscurity Won't Work".
Alex Bischoff
---
Alex Bischoff
HTML/CSS coder for hire
Languages don't make buffer overflows, programmers do.
Some people, including myself in the past few years, don't code in buffer overflows. I have never coded a message constructor with sprintf() like that. I haven't used gets() that I can recall. And I cannot remember when I ever did do any input without checking buffer size. I've been coding in C since '82 as well.
C and C++ are as strong and secure as the programmer who writes in them. Do the developers of Perl and Python put C/C++ coded buffer overflows in their code? I'm quite sure they do not.
now we need to go OSS in diesel cars
I think there is probably general consensus (here on Slashtot anyway) that "security through obscurity" doesn't work.
However, I believe that on the internet, the ubiquity of script kiddies is changing the rules.
The argument traditionally goes that people who want to compromise security will learn the "tricks of the trade." It's therefore in the interests of the securers to discuss exploits openly, or at the very least among themselves.
That last stipulation is the crux.
I think that exploits that are revealed by securers and crackers alike are broadcast across the internet so quickly and sometimes, in such a convenient fashion (like a little program in which you just "press the big red button") that an early and temporary "information quarantine" of this sort can make a lot of sense, as long as it's done right.
That's just my take, anyway.
--
Accountability on the heads of the powerful.
Power in the hands of the accountable.
Seems like BIND is a problem, and DNS in general is crazy. I'm in the process of trying out djbdns (in order to deal with the new BIND problems!) from cr.yp.to.
Check out this: http://cr.yp.to/djbdns/namedroppers.html. This is info on how closed the process of dealing with DNS issues already is. The guy that wrote this is the guy that wrote Qmail...
Please mod this up, I think it has important implications for this topic!
This is not about doing away with full disclosure: merely delaying it to make sure that critical parts of the Internet infrastructure can't be easily brought down by K3WL RAD SCR1PT K1DD13S. For "regular" users, this won't make a difference: even if they receive advance notification (say, 1 or 2 days), as soon as the new version hits the FTP server, every "hacker" idiot will be out there diffing the new version against the old and finding the security flaws
Exploits will still be on Bugtraq in a few hours, and the usual legions of K3WL RAD SCR1PT K1DD13 L00SERS will be on your servers anyway soon after that. The proposed group would just make sure the really important servers are difficult to exploit and that your vendor might have a fixed version available at the same time the new general BIND (in source format...) is.
I don't feel great about this, but only because I'm asking myself what happened to the Internet where users used to care, not mindlessly destroy each other's networks...
I don't think security through temporary obscrutiny [sic] is the way to go though.
Giving vendors a little jump on the crackers makes some sense. When a bug is announced, it's nice to have patches ready, too, and a whole mess of people ship BIND.
I'd be worried, though, that this would allow coverups; to prevent that from the start, they should make the mailing list archives automatically available after, say, 30 days.
Information control is usually harmful in the long run, but it can be helpful in the short run.
Just last week I had decided that BIND was just too much of a hog, and the past security issues always nagged at me. I got rid of Sendmaul three years ago for the same reasons and switched our mail servers to qmail; this time I decided again to use djb's software and did the work of installing djbdns, a pretty lightweight name server that does everything I need it to do.
Some of the things I have started to like about djbdns:
- Easily-parsible data file format
- Fast and lightweight, you can set it to use little memory and it will still work fine (my last day using BIND it had sucked 50MB of RAM)
- It's secure! While still remaining skeptical, and no matter what you think of djb, he writes damn secure code
- Return different answers depending on where the question came from; i.e. internal and external ip addresses get a different (or none) answer when
looking for foo.example.com. (did bind do this? not sure)
The easily-parsible data file format allows me to keep our DNS data in a mysql database and write tools to manage things easier--via the web, command-line, whatever. I would hate to have to hack together something to read/write bind's zone files (perhaps there is a tool already, I don't know off-hand, but I don't care any moreEven though I know BIND 9 is supposed to be completely different, it still does not engender my trust enough to use it any longer.
That's funny, because I'm paranoid and unpredictable, and that's why I have control of the firewall at work, for example.
It's not whether you're paranoid, Lenny, it's whether you're paranoid enough.
--
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
It seems you are not understanding, not me. Of course BIND is open source, and of course we all can go out to hunt that bugs and holes ourselves. But we will likely miss some of them.
Now imagine a list where new found holes are described in secret. No one else knows about it, no one else will fix it, before these guys decide, that the poor rest is now ready to get the news.
This is fine until some cracker finds his way into this list. That would be dreamland for him: Unpublished exploits, fearless targets out in the whole world.
Its a bit like security by obscurity. After all its just a damn dumb idea. Hiding the bugs or delaying the information about them will not fix them.
I can not see any positive thing is this, not a little bit.
The solution to these unnecessary bugs is not to form a closed mailing list to exchange information about the latest silly programming slips, it's to avoid the avoidable in the first place.
And you'd be wrong to think that I just hate C/C++: have used C since '82 and C++ since its first release (around '87?), and continue to use them. C and C++ are great for a variety of applications, and I write C++ code daily. But these languagse are not so great when trying to write software that withstands deliberate attacks and may have every boundary condition identified and exploited by an adversary. Would you drive your car without a safety belt? Raid a compound with armed terrorists without a bullet-proof vest? You may get away with it, but it just isn't prudent. So, why this complete disregard for basic and cheap safety precautions when it comes to security-critical programming?