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.
"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.
mike
spambait e-mail
my web site artistcorner.tv hip-hop music news
please help me make it better
if you see me, smile and say hello.
This list won't do dick to stop exploits.
- A.P.
--
* CmdrTaco is an idiot.
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
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.
--
Accountability on the heads of the powerful.
Power in the hands of the accountable.
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 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.
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
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.
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....
The only way to compete is to close the source and hide the bug list.
I wonder where they got the idea.
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?
Plead sanity, then they'll know you're crazy...
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.
It's 10 PM. Do you know if you're un-American?
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."
"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.
Nathan's blog
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.
-- Alastair
If we're going to undermine buffer overflows completely, we may as well go back to using Cobol or Fortran. No buffers there.
- I don't care if they globalize against free speech. All my best free thoughts are done in my head.
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.
Gorkman
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.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
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?
-- Alastair
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.
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.
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.
Gorkman
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
--
The more I learn about the Internet, the more amazed I am that it works at all.
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.
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
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.
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.
-
I've had enough abrasive sigs. Kittens are cute and fuzzy.
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
*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
On the whole, I find that I prefer Slashdot posts to twitter ones because I don't get limited to 140 chars before
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.
An Eye for an Eye will make the whole world blind - Gandhi
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.
-
I've had enough abrasive sigs. Kittens are cute and fuzzy.
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.
The secret of success is honesty and fair dealing. If you can fake those, you've got it made. (Marx)
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.
I think we've pushed this "anyone can grow up to be president" thing too far.
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!
------ Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind
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.
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
>
>
>
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.
I think Bruce Perens said it best -- "Security-Through-Obscurity Won't Work".
Alex Bischoff
---
Alex Bischoff
HTML/CSS coder for hire
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.
Edith Keeler Must Die
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.
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.
http://uptime.netcraft.com/up/today/top.avg.html
HINT: There are no Windows or Linux boxes!
Rank Site No. samples Average Max Latest OS Server Netblock Owner
1 sack.ees.com 17 897 906 906 FreeBSD Apache/1.3.0 (Unix) US Sprint
2 www.fks.bt 37 885 906 906 FreeBSD Apache/1.3.0 (Unix) US Sprint
3 www.charite.de 67 872 910 910 IRIX Netscape-Commerce/1.1 Universitaetsklinikum Rudolf Virchow
4 www.cult.cu 2 813 813 813 FreeBSD Apache/1.3.1 (Unix) Carthe Networks
5 www.cdl.cup.com 40 810 837 837 FreeBSD Apache/1.3.0 (Unix) Hopemoon Internet
6 cdl.cup.com 45 808 837 837 FreeBSD Apache/1.3.0 (Unix) Hopemoon Internet
7 bm98.cup.com 43 807 837 837 FreeBSD Apache/1.3.0 (Unix) Hopemoon Internet
8 69pornplace.com 50 759 785 785 BSD/OS Apache/1.3.0 (Unix) Verio, Inc.
9 www.yamagata-cci.or.jp 49 711 740 740 FreeBSD Apache/1.3.0 (Unix) Hopemoon Internet
10 cache.jp.apan.net 33 702 722 722 FreeBSD Apache/1.3.1 (Unix) Asia Pacific Advanced Network - Japan
11 203.181.248.20 40 698 722 722 FreeBSD Apache/1.3.1 (Unix) Asia Pacific Advanced Network - Japan
12 www.canadaplace.gc.ca 6 694 697 697 IRIX Netscape-Enterprise/3.6 BGS Advanced Server Farm
13 canadaplace.gc.ca 6 694 697 697 IRIX Netscape-Enterprise/3.6 BGS Advanced Server Farm
14 www.directinternet.com 17 679 687 687 FreeBSD Apache/1.3.9 (Unix) secured_by_Raven/1.4.2 NileNet, Ltd.
15 www.infoport.com 17 679 687 687 FreeBSD Apache/1.3.9 (Unix) secured_by_Raven/1.4.2 NileNet, Ltd.
16 www.sasg.com 12 672 678 678 FreeBSD Apache/1.3.12 (Unix) BiznessOnline
17 aed.org 17 664 674 674 BSD/OS Apache/1.2.4 Acadmey for Educational Development
18 www.superior.net 28 664 678 678 FreeBSD Apache/1.3.12 (Unix) BiznessOnline
19 iana.netnod.se 18 664 673 673 NetBSD/OpenBSD Apache/1.3b5 D-GIX Service network
20 www.rms.org 39 664 688 688 FreeBSD Apache/1.3.9 (Unix) secured_by_Raven/1.4.2 NileNet, Ltd.
21 solo.merita.fi 62 662 695 695 BSD/OS TANTAU Application Server/2.1.1 Union Bank of Finland Ltd
22 www.nilenet.com 49 658 688 688 FreeBSD Apache/1.3.9 (Unix) secured_by_Raven/1.4.2 NileNet Ltd
23 www.regalplastics.com 57 653 687 687 FreeBSD Apache/1.3.9 (Unix) secured_by_Raven/1.4.2 NileNet, Ltd.
24 bayern3.de 9 651 656 656 FreeBSD Apache/1.3.6 (Unix) PHP/3.0.9 Bayerischer Rundfunk
25 www.borica.bg 27 647 665 665 NetBSD/OpenBSD Apache/1.3.6 (Unix) Provider Local Registry
26 www.celticboxes.ie 6 647 649 649 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
27 www.aibifs.ie 7 647 649 649 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
28 www.alliance-francaise.ie 7 647 649 649 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
29 www.antiques.ie 7 647 649 649 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
30 www.arantours.ie 7 647 649 649 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
31 www.arc.ie 7 647 649 649 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
32 www.cllo.ie 6 646 649 649 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
33 www.automaticsprinklers.ie 7 646 649 649 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
34 www.dsor.ie 7 646 649 649 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
35 www.cti-clonmel.ie 6 646 649 649 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
36 www.ems.ie 7 646 649 649 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
37 www.fortune.ie 7 646 649 649 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
38 www.qadris.ie 7 646 649 649 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
39 www.eyecon.ie 7 646 649 649 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
40 www.u-haul-it.ie 8 645 648 648 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
41 www.activeireland.ie 8 645 648 648 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
42 www.ahca.ie 8 645 648 648 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
43 www.announcements.ie 8 645 648 648 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
44 www.apasystems.ie 8 645 648 648 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
45 www.ardtech.ie 8 645 648 648 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
46 www.ardtechindustries.ie 8 645 648 648 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
47 www.athlonecc.ie 8 645 648 648 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
48 www.atresonance.ie 8 645 648 648 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
49 www.banotti.ie 8 645 648 648 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
50 www.bercom.ie 8 645 648 648 FreeBSD Apache/1.3.6 (Unix) Internet Interactions
cpeterso
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.
I do not deploy Linux. Ever.
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.
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?
Patrick C. Lamoreux lamoreux@iastate.edu
(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.
Need a Python, C++, Unix, Linux develop
Interesting theory. Too bad it's completely bogus.
Sendmail and BIND are exploited more often than other applications with similar functionality for several reasons:
- Sendmail and BIND are widely used
- Sendmail and BIND are huge monolithic programs
- 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.
I do not deploy Linux. Ever.
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.
Need a Python, C++, Unix, Linux develop
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
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.
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.
... 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.
--
--
"What do you want me to do? Whack a guy? Off a guy? Whack off a guy? Cause I'm married."
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!
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.
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..
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).
Je ne parle pas francais.
And that, my friend, is why they are running our critical infrastructure and you are not. If something is not yet in the wild and being actively exploited, such as this recent bug, there is zero reason to speed to an announcement to the general public before critical systems are secured against it. The script kiddie exploits, in these cases, come after the announcement, not before.
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.
> I'd like to know why in the blazes "members" should be the only people getting the early warnings on security issues.
Yeah, and there's also the rather obvious problem of "What if it isn't a member that discovers it?"
Maybe we can partition the world into "members" and "non-members", and neither group will tell the other about the problems they discover.
--
Sheesh, evil *and* a jerk. -- Jade
This doesn't make any sense. You would rather risk the root- and TLD servers because you have some personal issues with one of the operators?
This is why people like you do not run our Internet infrastructure, and run things like EFnet IRC servers instead. Such attitudes are apparently a pre-requisite for that, but have no place for things of critical importance like our top-level DNS infrastructure. Personal issues aside, has Paul Vixie ever acted in a dangerous/untrustworthy way with respects to security issues of critical importance?
It didn't leak this time. The root nameservers were patched a week before word was released. I think that speaks for itself.
I'm perfectly aware of the whole MAPS/ORBS/AboveNet crap, but it has absolutely nothing to do with this issue here.
You're also looking at Vixie's code as it was written in the pre-script-kiddie days. You'll find that most ubiquitous software of that magnitude from that day also have similar vulnerabilities. Most anything written from scratch recently is significantly more secure. Including Bind 9.
Really I don't know why I'm defending Vixie or Bind here. I just think it's silly to go off on someone's codebase because you think it's "evil" or "unsafe" based upon your personal feelings about the author. If Linus Torvalds suddenly was convicted of some hacking charge, would you suddenly look upon the Linux source code with suspicion? Would you think of it as evil code whose authors have ulterior motives?
I could care less what DNS software you choose to use on your network, and in fact, I encourage non-Bind solutions. Heterogenity is a good thing.
Membership to this ISC group will be very tightly controlled and limited to those organizations that provide critical DNS infrastructure or are vendors that need lead-time to build and prepare updates to their clients. I suspect you are neither, and will have to wait for the public announcement of a security fix like the rest of us.
Note that they're not "hiding" this information. Stuff that isn't being actively exploited can stand to wait a few more days before being released, so that our critical infrastructure can be fixed up first. All they're doing is formalizing that process with an official membership roster.
That's the idea:
rpm --upgrade bind*
If we don't give the vendors any lead time before these vulnerabilities (which are not necessarily being actively exploited) are announced, how can upgrades like this be possible?
A "pre-release" group like this obviously won't do much good in the case where a vulnerability is discovered and is being actively exploited in the wild. That's not what it's there for. It's for those vulnerabilities that are discovered quietly, where the script kiddies haven't figured it out yet or exploits are otherwise not being used. In cases like that, the only sane thing to do is be sure the critical infrastructure is patched first, *then* move on to releasing the information to the general public. All they're doing is defining "critical infrastructure" and including vendors in that list, so that when the vulnerability *is* announced, people don't have to go compiling source code to secure their systems; their vendors will have an upgrade path all ready for them.
And we're not talking about a significant amount of time here. All they want to do is give a sufficient lead time to the systems that matter the most, and have everything ready for a quick and painless upgrade for the rest of us that need it.
1. Security through obscurity never works. What you'll end up with is the crackers knowing about the holes before the network admins do. All that does is help them cause more havoc.
2. Who decides whether or not you're allowed to know the "privledged" information. I run a network at home. Granted I don't allow DNS lookups through my external firewall, but the point is, just because I'm a home enthusiast do I deserve the ability to patch security holes any less than big companies, and where do you draw that line? Is a mom and pop web store that runs their own DNS for their domain (probably not many of those out there, but still) not allowed to know about holes in their system promptly? Are smaller operations not "important" enough to get the same level of information about security bugs in their networks?
If the answer to this is that anyone who runs a bind server should have the information, then you've opened it up to a wide enough community that you may as well make it public information anyway.
Unix is user friendly, it's just selective about who its friends are.
Oh yes, and of course all the potential members out there will handle their private keys absolutely secure? And of course the members are immune to other security bugs on their systems so that their systems cannot be cracked and the pgp binary cannot be replaced by a tempered-with one?
You may call it paranoid, i call it realistic. Take one person and you have 100% security. Take two persons and the security will be half. Now imagine how much people will be on that mailinglist. You simply cannot trust everyone.
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.
--
IMNSHO, This is a very bad idea. No matter how hard Paul tries, the information will leak out. There are simply too many people who would be on that list and don't give a rats ass about any NDA, or will refuse to sign said NDA. Many people live in countries where these NDAs would not even be worth the paper that they're printed on.
The only safe way to deal with this is to diseminate the information far and wide, in the hopes that everyone will update as soon as possible.
If an operator does not update their system, and gets comprimised due to the security hole, it's the operator's fault. If the system is comprimised, and information regarding the vulnerability was not released, it's the author's fault.
...si hoc legere nimium eruditionis habes...
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.'"
> 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.
This user does not understand any real delay and thinks the policy can be abusive.
Friends don't help friends install M$ junk.
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.
Yet another reason to just move off of BIND to
djbdns. Why go to all this trouble to be a part of a secure remediation
organization when you can switch away from a product that obviously NEEDS
a remediation strategy? I would rather use technology that has been
written from scratch with security in mind and has a track record to show
for it.
I think organizations like this lull people into the perception that if we
can just remediate fast and secretly enough we are safe from the latent
vulnerabilities that exist in the critical technolgies we use. This is a
huge trend in the industry with all these secret groups: IT-ISAC,
Infragard, etc.
What happens when it isn't a company that acts responsibly that finds the
next BIND problem? What happens if it is a person or organization with
malicious intent and they post the details publically? How is the secure
remediation group going to help?
-weld
- designed
- developed
- maintained
- protected
through obscurity.This attitude shows one thing to me, above all else. I can't trust BIND, because the developers can't trust BIND. A "good" design (eg: MAC for OS') =mandates= that the product comes before the egos of the developers. Any other approach is doomed to failure.
Essentially, BIND is now a dead product. Alternatives are appearing, and will keep appearing, and one (or more) will eventually supplant BIND as the de-facto resolver.
The more BIND is kept in the dark, the faster this will occur.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
It's obviously trivial for hackers to download and run an exploit script - so why don't we just do the same damn thing? Distribute scripts which make upgrading bind (and other packages) trivial. Don't make it harder for the crackers to get the exploit info - you must assume that there is always the potential for a leak. Instead, make it easier on the sysadmins, making it very simple for them to upgrade.
This list is to keep bug information to people that program with Bind. For Example, if you're a Redhat user, you will know that Redhat will buy into this, and therefore the Redhat patch will be out before the exploit becomes common knowledge and there is a downloadable kit that trashes a machine on it.
Combine this with Redhat's automatic update services, and you have used this to really help the business model.
If you are programming on Bind, you will be on this list (or should be on this list). If you just install Bind and don't touch the code, getting exploit information is of marginal benefit. However, giving info on the exploit makes it easy for someone who doesn't know much to code up an auto-exploiter.
This allows vendors to bust their ass on a fix before the vulnerability gets out.
There is an exception here. Right now, when there is a problem, people are in a frenzy to fix it. If this allows them to not feel as pressured to fix the bug, then this is very counter productive.
Alex
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?
The announcement email indicates that sensitive communication will be encrypted:
The reason they want to do this is simple. They found some massive security hole and don't want the public to know of it. This can also allow them to patch the important DNS servers and not have to care about Joe Blow's server.
This also means they don't have to tell the public of security holes until patches are found, don't have to admit to security holes outsiders find, and don't have to worry about any security holes. We all know that BIND, due to it's wide spread usage, has security holes and is one of the things to be hit the hardest. Then again, why does it have to have security holes? Apache doesn't have as many root exploitable security holes and it is widely used too.
If you are worried about null-terminated strings, perhaps in light of Theo de Raadt's estimate that half of all calls to stncpy() and strncat() were botched, there are alternative representations available that are easy to use correctly and have withstood extensive real-world testing.
Just because they create a secret forum... doesn't mean that they'll have the right to receive info first and foremost.
I cam imagine that it's quite a thrill to post on BIGTRAQ when you find a REAL BUG!!! I know I am thrilled anytime someone finds a bug in my code (really, I am).
I think that maybe Paul Vixie is growing weary of the problems in BIND.
But it is precisly the kind of cracking being done on BIND that makes it BETTER! Just because we have pain, doesn't mean that it's time to shut lips.
If we start putting GAG ORDERS on people, then what's to protect the OTHER users? Who's to say that this small band of people won't accidentally mis-classify a bug? Wheras a larger group of people you'd have alot more input on the problem.
I am firmly against this. Even if I decide not to use BIND, A class && TLD's bring us all together.
How much more angry will the response be to their group if it is found out that they withheld information that could have prevented serious exploits of many other entities.
And more importantly, what are the implications 25 years from now? What kind of role models will we have in security, and software in general?
Pan
I said no... but I missed and it came out yes.
Elite subculture turns more mainstream. Same thing happened to Ham Radio. On Ham Bands we have constant jammers, harassment, our version of script kiddies.
When it becomes easier to become a member of an elite subculture, it results in a breakdown of the basic respect of other members of the subculture.
-
I've had enough abrasive sigs. Kittens are cute and fuzzy.