Follow Slashdot stories on Twitter


Forgot your password?
The Internet

BIND Security Info For "Members Only"? 331

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.
This discussion has been archived. No new comments can be posted.

BIND Security Info for "Members Only"?

Comments Filter:
  • "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."

    Your statement above should be manditory for this group. Otherwise there will be little or no insentive for the group to close the exploit.

    Giving the private members a heads up on the latest weakness of a system, might force sytem operators to update and review their security more often. This of course will lead to beter managed webhosting/service sites. The ones that don't updates will be forced out fo business.

    spambait e-mail
    my web site hip-hop music news
    please help me make it better
  • So what happens when I discover a security hole and release exploit code for BIND to the public on Bugtraq using a Hotmail alias?

    This list won't do dick to stop exploits.

    - A.P.

    * CmdrTaco is an idiot.

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

    Good form on bugtraq dictates making vendors aware of the problem with plenty of time (typically two to four weeks) to put out a patch, before the bug is disclosed publically. Disclosing to everyone at the same time is definitely a party foul. The people that break this rule are either frustrated about the perceived lack of action on their report to the vendor (which, in BIND's case, would definitely not have been the case), or they're the k1Dd13s that are going to have just as much fun playing with zero-day sploits as they did finding the bug. Note that the closed BIND security group would not prevent hostiles from finding their own bugs, so neither of these exceptions are applicable.

    You can be sure that if and when the group is created, nothing will change. The bugs will still be found and fixed on bugtraq. Just now they might be preceded by about 10 minutes on another list.
  • I think there is probably general consensus (here on Slashtot anyway) that "security through obscurity" doesn't work. Are you ready to burn?

    However, I believe that on the fucking internet, the fucking ubiquity of script kiddies is changing the fucking rules.

    [Blah, blah, etc, etc...]

    This post just made my day. I'm convinced it was done with a perl script. I want it!

    Mod this up, it's hilarious.


  • by zzyzx ( 15139 ) on Thursday February 01, 2001 @07:39AM (#464173) Homepage
    A lot of readers are sure how you feel about this?
  • by rw2 ( 17419 ) on Thursday February 01, 2001 @08:44AM (#464176) Homepage
    Ok, who marked this insightful?

    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 can see it through my virtual eye...

    Some Crackers will crack there way into the mail spool of one of the authorized members of the list and will get access to exclusive cracking instructions while the rest of the world is without fear.

    Just another reason the kick BIND finally from my system.
  • by LiNT_ ( 65569 ) on Thursday February 01, 2001 @09:36AM (#464178)
    "Granted this is larger than djbdns, but this is no reason to abandon what is known to work, and work well."

    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.


  • I understand the reasoning behind wanting to have some time to work on a problem without the world's script kiddies causing the "immenent death of the internet" (or something equally bad) because everyone and their mother now knows the latest BIND exploit and a patch isn't ready yet. However, I don't think their method (inscrutible secrecy and legal agreements) is the best way to go. It seems to me that what they are basically looking for is time. Not an infinite amount of time, just enough to get a patch out before half the world knows about the bug.

    In the scientific community when they want to keep a new story under wraps for a while they "embargo it". It's a very standard practice. Essentially every news organization that wants to cover the story signs an agreement that they won't release details about the story before a certain date. When the date arrives, all news sources who have opted into the system have complete and accurate information about the story and release their own stories at about the same time. It's a way to prevent incomplete information, rumors, distorted facts, etc. from being scattered across the news media while the different organizations try to scoop and one up each other and while the researchers vainly attempt to get serious and correct all the errors and misinformation.

    It occurs to me that a similar system could be used for security bugs and breaches. Certain news organizations would be provided with all the information on the problem while agreeing not to release the details until after a certain date. It would provide the working time needed by the software makers to patch their product before the problem is exposed to the world in raw 1337 haxor friendly detail. The main problem I see with it is that most internet news organizations severely lack sophistication and organization news wise. However, I don't think it's anything that can't be worked around or surmounted.

  • Unfortunately this is not the case. String formatting problems, UTF-8 exploits and other major flaws are still found in pretty much every code base. It is simply the case that most code today that runs as root on machines happens to be in C. However as that changes so will the face of exploits. Just look at the number of formatting, encoding exploits in systems like IIS or CGI. In most cases those are language neutral...Switching from C to _enter language here_ does not solve the problem, it merely changes its form...creating secure programs is about good practices, not the using the flavour of the month language.
  • by macdaddy ( 38372 ) on Thursday February 01, 2001 @07:40AM (#464182) Homepage Journal
    They see bugs being exploited in mass causing huge problems for the Internet world at large and they want to minimize the number of people that here about the bugs before they're fixed. Understandable. I don't think security through temporary obscrutiny is the way to go though. My $.02.

    BTW, first?


  • by dubl-u ( 51156 ) <2523987012@potaG ... minus herbivore> on Thursday February 01, 2001 @07:40AM (#464185)
    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?
  • by mayoff ( 29924 ) on Thursday February 01, 2001 @07:41AM (#464188) Homepage
    Use djbsdns (from the author of qmail) if you want a secure DNS server. []
  • by fedork ( 186985 ) <fedor@apach[ ]rg ['e.o' in gap]> on Thursday February 01, 2001 @08:46AM (#464189)
    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.

  • by Anonymous Coward

    The only way to compete is to close the source and hide the bug list.

    I wonder where they got the idea.

  • There's an obvious response to this statement.

    If people like Vixie and his Nominum (BIND, Inc.) cronies were the ones FINDING the security flaws, instead of INTRODUCING them into the Internet infrastructure, maybe we'd have cause for alarm. After all, they'd be in an position to make yet another buck off the rest of the 'net --- this time in return for an "assurance" of protection against security flaws. Fuggedaboudit.

    The dirty little "secret" of the war between "script kiddies" and "security kiddies"---err, "white hats", is that the script kiddies who matter are getting the information first. Often, this is because they FIND it first. It doesn't matter if the "white hats" form yet another clique (anyone remember CORE?) and pat themselves on the back about how "clued in" they are.

    They're still going to find out about these problems when everyone else does. On Bugtraq.

    And Amen to that. The solution to this problem is not for bad software developers to bully users into using broken software. The solution is for clueful network operators to see the little guys behind the curtains for what they are, and replace their shoddy 80s-era software with proven, robust replacements.

    I repeat this observation ad nauseam on Slashdot. Here it is again:

    The same issues we're seeing here took place over the Internet mail infrastructure a few years ago. The solution was a secure mail server design proposed and implemented by Dan Bernstein, called qmail (reincarnated in Venema's qmail clone, Postfix).

    How many clueful admins do you know that still run Sendmail?

    How many clueful admins do you think will run BIND in 2002?

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

    My question is, who determines what's "right" or wrong in this situation...I personally feel that we all should have access to the information. Now I'm not saying that it wouldn't be nice to have a little forewarning, but given the prevalence of "share what you know" throughout the community, I don't think it would work.
    M$ has been doing this kind of thing for years and it hasn't worked for them, why would it work now?

  • C++. You can easily contain buffers overflows.

    You still are afforded with the convenient pointer clobbering facility of C, however. In general, the closer the code is to the machine, the nastier stuff it can do with things go wrong...and they will go wrong at some point.
  • by CharmQuark ( 200261 ) on Thursday February 01, 2001 @08:49AM (#464203)
    It seems that such a scheme treats security issues a public relations problem and not a technical problem. Although such a PR approach does have merit, as when the mayor of a large city asks the new agencies not to put every murder front page, computer security would not seem to qualify.

    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.

  • by jcr ( 53032 ) <jcr.mac@com> on Thursday February 01, 2001 @12:21PM (#464207) Journal
    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.

  • "Only a bad carpenter blames his tools"

    This saying rings very true, I think. You may claim not to hate C or C++ ,
    and I agree that you probably do not openly dislike them. But deep down
    inside, I think you despise the thought of programming in either of these
    languages because it makes you have to think. C and C++ don't allow you to
    just gloss over the details and assume that "the compiler will take care of
    it". Anyway, enough with ad hominem attacks, let me get on to the real crux
    of my disproof of your ridiculous argument.

    First, because a large amount of system software is written in C and C++ there
    will obviously be more system software with bugs written in C and C++ than
    other programming languages. Buggy, insecure code can be written in any
    language. Good, secure code can be written in C and C++, it just takes
    someone who is truly qualified to do so, not some loser IT with an MCSE to be
    able to do it. Just look at OpenBSD, it's written in C.

    Second, are you seriously suggesting that we trust our computer security,
    privacy and even lives to something as hideous as Java? Or another one of the
    "new and improvised" programming languages that seems to allow script kiddies
    whole new ways of breaking your system? Were you awake for the last half a
    decade? How many more Melissa viruses will it take to convince you that just
    about any language _other_ than C doesn't have what it takes to do reasonable
    security? Sure, Java may have it's sandbox, but the walls holding the sand in
    seem to be made out of paper.

    So basically I guess what I'm trying to say is C and C++ are just fine, if not
    much better, for programming secure software than other programming languages.
    We need to improve the programmers, not the programming languages. It's time
    to stop coddling software engineers and teach them what responsible
    programming really means. Courses on secure programming (in any language),
    and zero defect software design should be required curriculum for _anyone_
    writing _any_ software. If you don't know how to program well, your software
    is junk and should be deleted immediately.
  • I agree. The problem with BIND prevalence is the problem with any monoculture -- any bug that its susceptible too can take out the whole population.

    However, part of the problem is that the RFC's don't quite adequately specify everything, and the prevalence of BIND means that other DNS software has to take BIND's own quirks and interpretations of the specs into account. (Sound familiar? Like dealing with the products of a certain large and widely disliked software company?)

    Personally I think anyone running critical services like a DNS ought to not only have hardware backups, but back up software written by different authors. This is (or was, I don't know if they still do) the approach taken in the Space Shuttle computers: five identical computers, four of them running software by one vendor and the fifth, the emergency backup for the emergency backup, running software by a different vendor.

    As for myself, I'm switching to djbdns. I don't have the time to keep up with the BIND bug-of-the-month club.
  • I agree that C and C++ aren't the most secure languages for this kind of thing, but if not them, what languages would we use for stuff like this? Java?

    If we're going to undermine buffer overflows completely, we may as well go back to using Cobol or Fortran. No buffers there.

  • Ever wonder how warez and ISOs for things are usually released -before- the product is released? Its because somone in the 'members only' group of people that get pre-release copies of the software are in on it. What purpose will this 'members only' group serve? It sure won't keep people from making BIND exploits.
  • I don't think so. Look, I know JUST as many people who worked HARD for their Tech Pluses as some who worked for their Extra's. I personally would look no different on Extras who were a 20 wpm extra or a 5 wpm extra and the same should go for the Security stiff with BIND. Yeah, you get some idiots when it's easier to get a license or to become part of a group, but sometimes, just sometimes, even the idiots have good ideas.
  • It's not the language to blame. HOWEVER, some languages are more susceptible to weaknesses than others. It's (vaguely) like a gun without a safety: Still not dangerous when locked in a cupboard, but much easier to accidentally pull the trigger if you're being ever so slightly careless with it.

  • If no one knows about the security flaw except the BIND folks, then no harm done. But the minute someone else thinks of the exploit, I want to know about it that instant, preferably sooner.

    Now unless the BIND folks have some kind of double secret magical exploit detection powers that can instantly determine when an individual has figured it out, I'd just as soon hear from BIND right away when then know of the issue.

    I think BIND is just trying to cover their asses (which is fine.) I mean, it really should be responsiblilty of the sysadmins to keep their sites up to date with the latest patches. If they don't, they're fired, right?

    But what if someone uses this megahole to shut down the net? People (politicians, whoever) are going to look for someone to flay, and that someone is BIND.
  • Java compiled to native code (rather than interpreted bytecode) might not be a bad idea. It'll still be a bit slower than badly written C code, because of the internal bounds-checking, but probably about the same as securely-written C.

    I say let the compiler do the work, wherever possible. Isn't that the whole point of compilers?

  • Why should he have an opinion on everything!? The community is what makes /. unique.

    He "isn't sure how he feels about this" because the issue is subtle, involving balancing a variety of reasonable but competing needs.

    A lot of people on Slashdot, though, entirely miss subtlety. It was H. L. Mencken [] who said, "For every complex problem, there is a solution that is simple, neat, and wrong." On a bad day, that might as well be Slashdot's motto.
  • by RollingThunder ( 88952 ) on Thursday February 01, 2001 @10:15AM (#464247)
    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.
  • Only because that 31337 sub-culture will not "train" the script kiddies (be they ham radio jammers, or real script kiddies) from knowing right from wrong. I am sorry, but this ticks me off. I am a ham radio operator. I do not think that with the current rules, ham radio has gone down hill. Only reason it may have is because the elitest CW'ers think you should always learn old stuff before you can talk on HF phone. That's just BS. What does having to know CW have to do with talking on 10 m phone? NOTHING! What does it have to do with knowing how to setup a good antenna system? Nothing! Does not having to do anything but 5 wpm make it easier to become a Extra Class ham? I don't think so. CW is a mode of operation and nothing more. You should not have to learn how to use a specific mode before you even want/need to use it. YOu can carp about emergency preparedness all you want, but with computers getting smaller all of the time, whose to say they can't build a decoder right in a rig for decoding and sending CW? CW can be done better and even faster then 20 wpm by a computer. End of story. Sorry I rambled, but here's more on the topic:

    This is a bad move, no matter where you stand. Security by obscurity doesn't work. A good example is the ramen worm deal. When I heard about it, I was already patched. I was concerned, but not too concerned because I apply patches as soon as they are available like any good sysadmin should! By obscuring the problem a script kiddie can already have exploited the problem before I find out and that's bad! Also, if there is a problem and you know it but don't know how to fix it, by publishing it, you might have an attack, but then again you might get hit by a slew of patches fixing it. A system can only be more secure by having more eyes look at the code and more eyes that know there's a problem with the code looking for it.

  • We're talking about root- and top-level-nameservers here, not second-level domains. Things like ".", "EDU.", "ORG.", "COM.", etc., are the ones we're worried about. The critical infrastructure needs to be addressed first. The second-level stuff can (in cases such as this) wait for the public announcement.
  • None of this changes the behavior of ISC with respects to disseminating information regarding newly discovered (but not widely known or exploited) vulnerabilties. Not at all! Presently stuff like this is discovered, patches written, root- and TLD-nameservers are upgraded, and *then* the vulnerability is announced and upgraded provided to the general public. All they're wanting to do is make that process official by creating a membership that includes other critical infrastructure parties and vendors into that list of people that get early warnings.

    If I had a RedHat system, I know it would be very nice to see an urgent advisory like this appear and have RPM's ready and waiting for me to install to secure my system. At the moment, everyone has to rely on source code. What if you're merely using a BIND-derived nameserver? You have to wait for your vendor to release their own version, which can be a pretty scary thing. This simply aims to eliminate that problem.
  • It helps if the vulnerability isn't being actively exploited, and if it gives you time to fix up the critical root and TLD nameservers before the script kiddies even know about it.
  • 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
  • ISC will, as they say. I do not anticipate membership to an organization like this to be given lightly, or to anyone at all that can't demonstrate a critical need for it. Root- and TLD-level nameservers, yes. Registrars, perhaps. Major ISP's? Maybe. Major companies? Doubtful.

    But then again I'm not ISC. I can't imagine something like this working, though, without a very tightly limited list of members.
  • Bind 9 is also of a completely different codebase. It's also more compatible, more powerful (offering most anything Bind 8 does), and arguably more stable/trusted.

    Though I'm not trying to reduce the number of people using alternative DNS products (heterogenity is a good thing). I just don't like to see something like BIND get trashed for no good reason. Bind 9 has little in common (besides features and compatibility) with Bind 8.
  • by Skapare ( 16644 ) on Thursday February 01, 2001 @01:23PM (#464262) Homepage

    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.

  • You'll find the same holes in lots of software written in the "pre-script kiddie" era. Lots of education has come about in the last 5 years or so, and most any piece of software written (from the ground up) in the last 2 years will be significantly more secure than something equivalent written 7 years ago.

    All the more reason to upgrade to Bind 9 instead of sticking with the Bind 8 codebase.
  • Only because that 31337 sub-culture will not "train" the script kiddies (be they ham radio jammers, or real script kiddies) from knowing right from wrong.

    Well, you are right about ham, in some ways. I would argue that harder tests, (not really CW) require higher intelligence, and thus, filter out the idiots that would do stupid disrespectful stuff like jamming. Intelligence aside, at least it filters out the people who don't care enough about the hobby to put the work into it, to learn the basics.

    I know the older elitists hams look down on 5wpm extras, but put yourself in their place, they had to work hard for their license, and now it's a lot easier to get, regardless of whether their work was really necessary or not.

    I am not arguing for elitism, I am just making an observation. Maybe ham isn't a perfect analogy of the security issue at hand, but there are parallels, it became easier to become a part of an elite subculture (the internet, and unix in general, or ham radio), and the respect for fellow members went down.

  • by Skapare ( 16644 ) on Thursday February 01, 2001 @01:32PM (#464270) Homepage

    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.

  • *sighs* After literally years of preaching "always notify the developer first, and only send to bugtraq if the problem is not resolved" and people acting in good faith with the developers, we get this.

    This will set back co-operation in the security field by years.

    Remove the rocks to send email

  • But then most security people are the most paranoid people on the planet so it makes some sense.

    Ummm guess it must be the real world then.
  • Its probably because a contract isn't binding (BINDing? :) in the US unless there is an EXCHANGE of consideration.

    If I agree to give you something out of the blue, with no consideration (money, stuff, services) from you, then there is no binding contract.

  • Its all well and good having a closed group, this doesn't address that people outside this group may find the flaws, and craft the exploits.

    Full disclosure is the best way. It ensures that maximum exposure for problems is achieved. Without which many users will be unaware that software they are running is vulnerable.

    This is particularily important with OSS: With closed source the vendor will usually know who is using its software...

    The main sources of news for the OSS community from a user's perspective is forums like bugtraq and slashdot.

    Closing a forum or obscuring flaws behind an eliteist facade is no answer.

    This will only serve to lengthen the time to fix. We all know how long it takes some vendors to release security patches. Take a look at the recent macromedia problem, where it was only once the problem hit bugtraq that they did anything about it.

  • C and C++ can be written safely, if only the person programming takes care to make their programs safe.

    Of course. But they aren't. And they don't.

    I'll accept theoretically that its possible to write C code that isn't succeptable to these things. But it virtually never happens.

    Conversely "safe" languages don't guarantee anything. But, code writen with them in the real world is vastly better than code in C and C++, at least with repect to buffer overflows and memory leaks.

  • Do you consider yourself more deserving of patches/alerts than the root-level nameserver operators?

    That's just silly. Critical infrastructure is by definition critical, and they need advance warning (if at all possible). If a vulnerability is already public and exploits are in the wild, then a group like this doesn't serve any practical use and should (and likely will) be circumvented in favor of more direct announcements and patch releases.
  • Well I don't write C++ code daily. Or ever if I can help it. But the last rating I saw said that code that used the STL was almost twice as large and almost twice as slow as code that did the same thing more directly. This can easily be an unacceptable penalty.

    OTOH, based on what I know of Ada, there isn't any need for this kind of penalty.

    Perhaps the libraries and compilers have improved since I saw the benchmark (2-3 years ago), as I indicated, I don't keep up on C++. But C/C++ really does seem like an extremely poor choice for a language to do secure programming in. It's not just buffer overflows. The flagrant use of pointers and casting is nearly as bad, even if that doesn't open any obvious holes for external breaches.

    Caution: Now approaching the (technological) singularity.
  • System admin is not an easy job, and if you want it easy you should go work for McD. Distributing a script that makes it easy to upgrade is not the answer, think of some script kiddies distributing their own trojan upgrade scripts. If you don't take the pain to verify source of script and checksum, you will be owned!
  • As the former FreeBSD security officer, I can tell you that we sat on information about exploits until fixes were in the tree, except for those folks that needed to know. Once we released an advisory, which didn't contain exploits, usually the exploits that we used to test our fixes appeared in Bugtraq. Sometimes with a very long lag.

    In the security biz, sometimes short term non-disclosure can be beneficial. So long as it is short term and you don't rely on it for the long term security of your system.

    Also, the time lag that we like to see is closer to a week than 2 days since it lets us get a good advisory written, as well as doing better testing to see if other exploits are possible that the first one wouldn't find in testing, etc. We actually like to work with the folks that bring these to our attention so that we can make sure that our developers have had a chance to fix the problem before the release goes out (as well as informing other parties that we think might be using the same code base). Sometimes this means asking them to sit on things a little longer if the bug turns out to be hard to fix. Other times it means sending them a "go for it any time" and waiting a while for them to release their advisory so they get credit before we release ours.

    I don't think this will be used to sweep security issues under the rug. Rather it will help those folks that intergrate BIND into their base OSes, like FreeBSD does, to provide more timely updates to their source bases so they don't open a window of opportunity for the bad guys to hit the user community.

    It comes down to balance and common sense. in the end.

    Warner Losh

  • You're crazy, dude. I agree that Java isn't the most well-designed language (there exist a number of better choices). Yet, I challenge you to show me a plausible piece of java code (not something that shells to the system) in a network application setting which allows a mischevious remote user to execute code on the host.

    There are plenty of examples of plausible C code which exhibit this behavior. (cf BIND)

    Just using a safe language isn't enough, but it sure is a start!
  • There are TWO reasons why BIND gets exploited. Number one is that a fix to an exploit is not made available. Number two is that administrators don't upgrade to install fixes to exploits. What Paul Vixie wants to do is make sure both reasons work to ensure thousands of exploitable DNS servers around the world.

  • by grappler ( 14976 ) on Thursday February 01, 2001 @10:46AM (#464291) Homepage
    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.
  • by Dr. Awktagon ( 233360 ) on Thursday February 01, 2001 @07:45AM (#464292) Homepage

    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?

  • by iota ( 527 ) on Thursday February 01, 2001 @10:46AM (#464293) Homepage
    I'm sure this has all been mentioned before.

    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 ;) 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.

    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 machines hard enough, and almost simultaneously, then we would have a problem.
    A big problem.

    -- jason
  • by jayfoo2 ( 170671 ) on Thursday February 01, 2001 @07:46AM (#464295)
    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.
  • by lupa ( 218669 ) on Thursday February 01, 2001 @07:47AM (#464299)
    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?
  • by Eric Seppanen ( 79060 ) on Thursday February 01, 2001 @10:49AM (#464300)
    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.

  • by jalbro ( 82805 ) on Thursday February 01, 2001 @07:47AM (#464303)
    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
    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?


    > cricket

  • by Anonymous Coward
    You know, this wouldn't be such a big issue if they'd just stop adding new features for a few months and focus on security alone. Do a thorough audit like the OpenBSD team does. Once it's been gone over again and again, THEN worry about adding new features.
  • by abischof ( 255 ) <alex.spamcop@net> on Thursday February 01, 2001 @07:48AM (#464310) Homepage
    I think Bruce Perens said it best [] -- "Security-Through-Obscurity Won't Work".

    Alex Bischoff
  • There is no infrastructure to support DNSSEC, so including it in djbdns is a useless exercise at this time. When NSI starts collecting keys and signing records, then DNSSEC will be supported in djbdns. Bernstein has said as much, though he'd rather see a system put in place that does not depend on one centralized key server, which, if compromised, blows the whole system. He says he's developing such a system.

    Also, many people use tinydns with a mysql backend. Check out the djbdns mailing list to find out who and how.

    One of the hallmarks of tinydns is how flexibly it can be managed. The data file format is very easy for common text manipulation tools to deal with.

  • Have you actually looked under the STL covers? STL makes virtually no guarantees about runtime safety. If you make mistakes with STL, the runtime behavior is often even more subtle and odd than with raw pointers. Besides, C++ still has lots of other ways of unintentionally producing unsafe code, and introduced quite a few new ones.

    The string class in C++ happens to be a little safer than using raw malloc'ed buffers in C, but for that minimal level of safety and convenience, there are also good string libraries for C.

    The practical record on runtime safety and freedom from buffer overflows in C++ is also not so good if you look at the various Microsoft products.

  • You are completely right: using a safer programming language than C or C++ doesn't guarantee safety. But it's false to infer therefore that using a safer programming language doesn't help. Electrical fuses, safety belts, and air traffic control don't guarantee safety, but they guard against common problems. Furthermore, if you don't have to worry about string buffer overflows all the time, you have more time to worry about the other problems.
  • I fully agree: it's a question of resources and tradeoffs. With enough resources spent on design, testing, and code-review, you can make asm and C programs very safe and secure. But the empirical fact is that most real-world software is not constructed that way.

    While no programming language guarantees safety, a language with less disregard for safety than C/C++ appears to be able to substantially lower the cost and effort involved in producing software that is as safe and secure as equivalent C software that took a lot more time and money to produce.

  • You linked to this month's most requested site uptimes. That is not the same longest uptimes overall. Please see the following link for Netcraft's longest uptime chart: []

    HINT: There are no Windows or Linux boxes!

    1. Rank Site No. samples Average Max Latest OS Server Netblock Owner
      1 17 897 906 906 FreeBSD Apache/1.3.0 (Unix) US Sprint
      2 37 885 906 906 FreeBSD Apache/1.3.0 (Unix) US Sprint
      3 67 872 910 910 IRIX Netscape-Commerce/1.1 Universitaetsklinikum Rudolf Virchow
      4 2 813 813 813 FreeBSD Apache/1.3.1 (Unix) Carthe Networks
      5 40 810 837 837 FreeBSD Apache/1.3.0 (Unix) Hopemoon Internet
      6 45 808 837 837 FreeBSD Apache/1.3.0 (Unix) Hopemoon Internet
      7 43 807 837 837 FreeBSD Apache/1.3.0 (Unix) Hopemoon Internet
      8 50 759 785 785 BSD/OS Apache/1.3.0 (Unix) Verio, Inc.
      9 49 711 740 740 FreeBSD Apache/1.3.0 (Unix) Hopemoon Internet
      10 33 702 722 722 FreeBSD Apache/1.3.1 (Unix) Asia Pacific Advanced Network - Japan
      11 40 698 722 722 FreeBSD Apache/1.3.1 (Unix) Asia Pacific Advanced Network - Japan
      12 6 694 697 697 IRIX Netscape-Enterprise/3.6 BGS Advanced Server Farm
      13 6 694 697 697 IRIX Netscape-Enterprise/3.6 BGS Advanced Server Farm
      14 17 679 687 687 FreeBSD Apache/1.3.9 (Unix) secured_by_Raven/1.4.2 NileNet, Ltd.
      15 17 679 687 687 FreeBSD Apache/1.3.9 (Unix) secured_by_Raven/1.4.2 NileNet, Ltd.
      16 12 672 678 678 FreeBSD Apache/1.3.12 (Unix) BiznessOnline
      17 17 664 674 674 BSD/OS Apache/1.2.4 Acadmey for Educational Development
      18 28 664 678 678 FreeBSD Apache/1.3.12 (Unix) BiznessOnline
      19 18 664 673 673 NetBSD/OpenBSD Apache/1.3b5 D-GIX Service network
      20 39 664 688 688 FreeBSD Apache/1.3.9 (Unix) secured_by_Raven/1.4.2 NileNet, Ltd.
      21 62 662 695 695 BSD/OS TANTAU Application Server/2.1.1 Union Bank of Finland Ltd
      22 49 658 688 688 FreeBSD Apache/1.3.9 (Unix) secured_by_Raven/1.4.2 NileNet Ltd
      23 57 653 687 687 FreeBSD Apache/1.3.9 (Unix) secured_by_Raven/1.4.2 NileNet, Ltd.
      24 9 651 656 656 FreeBSD Apache/1.3.6 (Unix) PHP/3.0.9 Bayerischer Rundfunk
      25 27 647 665 665 NetBSD/OpenBSD Apache/1.3.6 (Unix) Provider Local Registry
      26 6 647 649 649 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
      27 7 647 649 649 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
      28 7 647 649 649 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
      29 7 647 649 649 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
      30 7 647 649 649 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
      31 7 647 649 649 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
      32 6 646 649 649 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
      33 7 646 649 649 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
      34 7 646 649 649 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
      35 6 646 649 649 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
      36 7 646 649 649 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
      37 7 646 649 649 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
      38 7 646 649 649 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
      39 7 646 649 649 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
      40 8 645 648 648 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
      41 8 645 648 648 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
      42 8 645 648 648 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
      43 8 645 648 648 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
      44 8 645 648 648 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
      45 8 645 648 648 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
      46 8 645 648 648 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
      47 8 645 648 648 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
      48 8 645 648 648 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
      49 8 645 648 648 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
      50 8 645 648 648 FreeBSD Apache/1.3.6 (Unix) Internet Interactions

  • We converted my multi-billion dollar employer to djbdns [] on the majority of externally-visible IP addresses, and took some flak for it.

    This was about a month before the big BIND vulnerability became public. The timing wasn't ESP, it was pro-active security, but it sure made our group look good when the announcment hit 'mainstream' news sources.

  • So basically I guess what I'm trying to say is C and C++ are just fine, if not much better, for programming secure software than other programming languages.

    That's what you are saying, but I still think you are completely wrong. I hope you would agree that it would be crazy to design a car in such a way that the malfunction of the radio can easily make the whole car explode. But that's the way C/C++ work: bugs anywhere in a C/C++ program can have completely unpredictable, non-local, and unbounded consequences. There is no way in C/C++ to contain faults. Buffer overflow exploits are only one of many problems resulting from this language design problem.

    Second, are you seriously suggesting that we trust our computer security, privacy and even lives to something as hideous as Java? Or another one of the "new and improvised" programming languages that seems to allow script kiddies whole new ways of breaking your system?

    Most languages, historically, have had excellent support for safety; C and C++ are the aberrations.

    As for Java-the-language, I don't see anything particularly wrong with it. It's a very simple OO language. It's 30 year old technology. It's a conservative design. The JVM is pushing the limits, but you don't have to implement Java on a JVM. If Java is not to your taste, Modula-3 is more powerful and just as safe.

  • This already occurs with exploits.

    The 'CORE' mailing list was similar to what is proposed for BIND, and archives were actively traded between hackers in the late 1990's. I still have a copy somewhere.

    Exploits for 'statd' were traded in the underground for years before the problem became public.

  • I run a few nameservers using Bind... When there are updates, I upgrade. I don't care if I can't know about an exploit first thing. I just want to be able to get the patch as quick as possible...
  • Seems fairly worthless to me to do this. Firstly someone will talk, someone always talks, second I would think the more capable minds you have working on this the more likely you would be to produced effective solutions to the problem. Besides if the risks are there, should the users be the first to know? Isn't that what its all about?
  • If all the NDAs stipulated a finite time period of not more than 7 days, allowing anyone to release the information at that point, then I would believe you. 7 days is plenty for a vendor to get their act together. In fact 1 business day is enough, really. But I'll allow for 7 given that there are always stupid managers getting in the way of real work.

    Instead, this is a means to allow Paul Vixie to cover things up while he doesn't make much effort to fix it. Someone who continues to release known bad programming methods isn't likely to be very adept at rapidly fixing exploits anyway. And this secretive approach only means the rest of us have to sit around like mushrooms while the cracker nets are passing the info around in their own secretive ways to avoid getting caught.

  • One thing that I haven't heard during all the recent bind hoopla is whether or not the security holes affect copies of bind that're running chrooted and under their own uid/gid. None of the security advisories seem to mention this issue. Anyone got any ideas?

    (Not that I didn't upgrade, anyway. But it'd be nice to know that the extra effort of getting bind to run chrooted was worth it.)

  • I've written C++ code that is largely immune to buffer overflows because of the manner in which it's written. It's actually not too hard to do, and simply requires a different mindset when dealing with the code.

  • I theorize that if DJB-DNS and qmail were as widely used as BIND and sendmail that both of the former applications would see their share of exploits.

    Interesting theory. Too bad it's completely bogus.

    Sendmail and BIND are exploited more often than other applications with similar functionality for several reasons:

    1. Sendmail and BIND are widely used
    2. Sendmail and BIND are huge monolithic programs
    3. Sendmail and BIND were not originally written with security in mind.
    The 'limited userbase' aspect of QMail and DJBdns may be one factor in the LACK of exploits for those applications, but the other two factors are much more important.

    Qmail and DJBDNS are composed of massively fewer lines of source code, are much less complex with less support for legacy functionality, and were designed from the ground up to be secure.

    There are fewer exploits of Dan Bernstein's applications than Paul Vixie's because Dan's code has fewer bugs to be found and exploited. djbdns is inherently more secure than BIND, regardless of the number of sites using it.

  • djb's license in a nutshell: you can redistribute the tarballs AS IS freely. You can distribute pristine binary packages freely. You can use / modify freely, but you can only distribute modifications as patches.

    I agree, it's a *major* pain in the ass, but would you rather have some bloated, compromised, resource hogging, buggy crap like Bind or sendmail on a 'mission critical' service like DNS or mail?

    And then, while it's a pain in the ass, it's still *free* software. Annoying license, but still free (just like the Qt licence).


  • As an addendum, almost any code written for The StreamModule System [] is immune to buffer overflows because of the way buffers are handled. It's really not hard. The tools are available.

  • Interesting. Perhaps it is easier to administer. But I hope it isn't as hard to do a startup as qmail was with daemontools. I hope it doesn't have as many processes running as qmail did. And I hope it uses no more than a single userid. As for configuration, it looks like it's command oriented while I prefer file oriented (e.g. my own scripts generate all the files from data stored elsewhere anyway). But this operates in a total replacement mode since they can't really determine incremental changes reliably. I should be giving it a try in the next couple of weeks.

  • by Skapare ( 16644 ) on Thursday February 01, 2001 @11:35PM (#464347) Homepage

    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.

  • Over the years I've collected a few string functions I've written. I'm starting to write some more, and I'll be releasing the library in the next few months. OK? Tell me what kinds of functions you'd like to see in C.

  • by kyz ( 225372 ) on Thursday February 01, 2001 @07:54AM (#464351) Homepage
    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.

    Well, while I can see your point, Script Kiddies don't really care if bugtraq posts an exploit or not. They get their exploits from l33t d00dz, not bugtraq. Besides, when is the right time to post an exploit? Good sysadmins want one immediately to see if they're in danger. Bad ones never want one, because they don't know or care there are security holes in their software until a kiddie reminds them that bugtraq is not the only sploit source.
  • by DeadVulcan ( 182139 ) <dead.vulcan@pobo[ ]om ['x.c' in gap]> on Thursday February 01, 2001 @07:54AM (#464353)

    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.


  • Except for two small problems. One, every comprimised box becomes yet another weapon to use in a DDoS attack. Two, recovering from a comprimise is an incredible pain and takes a lot of time and effort.

    This is regardless of whether or not you kept 'top secret' information on a box connected directly to the Internet or not.

    Lastly, you are obviously a complete jerk and idiot since you can't seem to make any point at all without resorting to abusive language and calling people names.

  • by msuzio ( 3104 ) on Thursday February 01, 2001 @07:54AM (#464359) Homepage
    I think the biggest problem here is that BIND is *so* widespread (maybe even more so than sendmail?), when a bug breaks, it is immediately a major exploit waiting to happen.
    When the latest BIND 4/8 bugs hit, people were reporting attempts to exploit the bug almost immediately. That's really bad.

    So, is it OK to do this in an attempt to give the good guys a jump on the bad guys? Maybe. I'm very leery of any circumstance where bugs are actively hidden. I do believe that disclosure is key in any security situation. That having been said, I don't think that a closed list which agrees to discuss bugs locally before full disclosure is all bad.

  • ... because everyone knows that all "TLD" operators are good people and would never use security bugs to break into someone else's system.

    Paul Vixie is just full of good ideas. I want to be like him when I grow up.

    I have an idea. Let's limit the bug reporting system to people whose mail servers block mail from people on the MAPS RBL. That way we'll kill two birds with one stone.

    Fuck Paul Vixie with a big rubber dick.

  • Paul Vixie is a very, VERY good man
    But this time he's TOTALLY, 100% off base. This goes totally against everything the Net ever stood for, back before the GPL when code was Free as in Beer. If Open Source is to have a snowball's chance of beating the Cathedral types, we can't let a major cornerstone piece of software go even one iota closed source. It's totally indefensible.

    Our reputation is staked on the idea that many eyeballs makes all bugs shallow, and that we can, in most cases, fix things faster than the script kiddies can exploit it. Please note that the most notable DNS problem in our short memories was on MICROSOFT servers, not Mr. Vixie's precious code. Matter of fact, MSFT went to Akamai precisely because they were running Linux and BIND - something they knew wasn't easily hacked.

    Open Source is not broken, Mr. Vixie. It doesn't need to be hidden under a pile of NDA's, much less "fixed." If you go thru with this hair-brained idea, I'll be one of a very large number of people to unceremonously consign your code to /dev/null. I may do so anyway, just to make sure the old Cabal isn't pulling stunts on me behind my back.

    No, I haven't forgotten you were once a junior member of that once august organization.

    Rate me down if you want to, Moderators, I've got karma to burn. But IMNSHO, this effort against the very core of Open Source must be stopped, cold, and in such a way that no one ever thinks of doing it again.

    (I wonder what would happen if someone forked the code at this juncture and GPL'ed it?)

    There is TOO a Cabal.
    Where the hell is spaf when you need him?

  • by supton ( 90168 ) on Thursday February 01, 2001 @07:55AM (#464363) Homepage

    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 [].

    Check out this: []. 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!

  • In the end, this will make very little (if any) difference at all because I think the biggest problem is not really how fast a patch is produced (the open source crowd is already well know for the speed at which they produce patches), but how long it takes for people to install them! For example: the recent Red Hat worm - Red Hat had patches for it months ago, and yet this worm still made major damage. Why? A lot of very very very lazy (or incompetent) sysadmins.

    Now, if you can address THAT, then that'd be progress.
  • can someone else explain the purpose of the fee to me?

    Pure speculation, but it might just discourage people from joining on a whim.
    'Keeping out the riff-raff' so to speak.
    Maybe they think people can be more trusted with sensitive info if they've bought it, rather than had it given to them.

    Then again it might just be because they want to make a buck.

  • I don't think you can follow the normal software security model with BIND. Maybe with MS products you can advocate full disclosure in all situations. What are you seriously going to do to cause widespread "net terror" with a microsoft exploit? However, say you are checking your bugtraq mail on a late saturday night and somebody, following full disclosure, posts an exploit for the latest version of BIND. Of course the TLD operators and the root operators are probably sleeping while you hack into a root or TLD server and cause widespread "net terror". Just imagine how much damage you could cause with a rooted tld or root server. The root and tld operators (and every legitimate net user) deserves to have the root and tld operators absolutely find out about the exploit before you or I do. I don't see how you can argue against that.

    P.S. I know using the phrase "net terror" is lame.
    Make fun of me if you must.

  • like dnssec, backending into a database, etc.. try bind 9 if you want to stay with bind and alleviate yourself of the bug-ridden 8.x series..
  • by mdb31 ( 132237 ) on Thursday February 01, 2001 @07:55AM (#464379)
    You're reading this wrong: Vixie is proposing to form this 'support group' in response to criticism that only the root and some TLD server operators were notified in advance about the latest BIND emergency fix release. A lot of people were asking "why weren't we told in advance about these bugs, and this is the answer. This proposed group (now with public membership rules instead of a "secret handshake") would know about new BIND emergency maintenance releases a few days/weeks before they would be generally available, allowing them to safely upgrade.

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

  • If you're going to believe the discussion from two days back, it seems most people are willing to continue using BIND because
    a) it's GPL (which overrides any securiy problems anytime)
    b) the secure alternative is not GPL
    c) it's been pounced on so much so far, surely it has to be secure by now (well, until the next security bug shows up at least. Go back to a) if you have any doubts).

  • by dubl-u ( 51156 ) <2523987012@potaG ... minus herbivore> on Thursday February 01, 2001 @08:00AM (#464401)
    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.
  • by SgtAaron ( 181674 ) <> on Thursday February 01, 2001 @08:17AM (#464440)
    It's an amazing coincidence that I was in the process of ridding our network of BIND forever when I saw Paul Vixie post to NANOG. That was last Friday evening, three days before I saw anything about this on Bugtraq.

    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 (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 more ;-). It's nice to be running a piece of software that I know will not enable the script kiddie next door access to my network.

    Even though I know BIND 9 is supposed to be completely different, it still does not engender my trust enough to use it any longer.

  • But if you read his website he comes across as paranoid and unpredictable. I don't want to trust the security of my clients' systems to someone like that.

    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.


  • by kju ( 327 ) on Thursday February 01, 2001 @08:05AM (#464446)
    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.
  • by MartinG ( 52587 ) on Thursday February 01, 2001 @08:09AM (#464452) Homepage Journal
    So what do you say to the ppl whose boxes are exploited in the meantime?

    BIND user: My box was exploited because of a buffer overflow bug that we didn't know existed.

    BIND bug ppl: Ah yes, we knew about that but we didn't tell anyone in case script kids heard about it.

    BIND user: Great. Now all our top secret info had been stolen and it could have been prevented. If you made the bug public then WE could have decided what was best, and possibly taken the machine(s) offline until there is a fix.

    Think of it this way. If it was discovered that there was a really easy way of unlocking all existing house doors, would you want that information hiding temporarily in case criminals learned about it or would you want to know so you could at least have a chance to board up the doors if you thought it was neccesary. Making the expolit information available to all admins (regardless of whether the hax0rz also know) puts the admins in control which is the right thing to do.

    Also, the problem with this stupid idea of limiting information spread is that it assumes the script kids are more on the ball than the admins. If that _is_ true, then _that_ is the problem that needs solving because in the end a poorly administered box will always be cracked however slowly or quickly you get the exploit info out.
  • by q000921 ( 235076 ) on Thursday February 01, 2001 @08:10AM (#464457)
    How many more buffer overflows and compromises of key Internet infrastructure is it going to take to finally convince people that it is irresponsible to write security-critical software in C or C++? Buffer overflows are pretty much the domain of C, C++, and assembly language. Almost all other languages protect against them, at negligible compile-time and runtime cost. Many C/C++ hackers claim and think that they don't need this sort of thing, but the fact that 15 years after the Internet worm, these things still keep cropping up shows otherwise.

    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?

  • by Jedi Alec ( 258881 ) on Thursday February 01, 2001 @08:12AM (#464460)
    That's an easy one. When discussing anything M$, government or big-company related, you're supposed to feel sick, nauxious, disgusted, like going to the bathroom etc. When discussing open-source, *nix, big companies that are good at pretending they're not big companies(read: AMD) or Natalie Portman, you're supposed to feel all warm and tingly inside. Now we just need CmdrTaco to include this in the guidelines for the site, and life will be a lot easier on the moderators as well.

10.0 times 0.1 is hardly ever 1.0.