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.
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.
--
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
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.
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
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 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?
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 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.
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.
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.