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.
Mr. Paul Vixie (just the secret identity of INTERNET ETIQUETTE MAN!!!!!) will, of course. God knows, he's the ONLY one fit to judge what everyone else should and should not do/see.
'nuff said.
--------------- Murphy was an otpimist.
Ah, if only we were all so lucky. There's just something about DJB's stuff that has really turned me off. I suppose it's because he writes fairly small modular programs. If you want to do zone transfers you need to get other programs to do that. If you want to run the damned thing you have to install daemontools, etc. With bind everything is included in a nice easy package to save admins a LOT of headaches.
Haven't checked, but I believe it is under a BSD-style license.
More probably, one member will encrypt the juicy stuff with PGP, create a Hotmail account through Anonymizer and relay the info to a trusted party who'll let everybody know about the latest security hole in BIND.
there's also tcpserver, which is a replacement for inetd, btw
--
"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.
If there are problems with BIND, then the users should know about them and be prepared for possible exploits. If this succeeds, the only people who will know about the security problems with BIND will be the "BIND Elite", and "The h4xors".
I want my rights back. I was actually using them when our government stole them after 9/11.
I guess that depends on your definition of "really important".
Hmm..... Let's try this scenario:
I run my e-biz and depend on BIND for nameserving. It is attacked and my customer records are compromised. I could have received an update IF I had paid for the priviledge of being a member. But my business is now ruined because the notices of expolits were kept to an exclusive list of 'insiders' who had advance knowledge.
Sounds like M$ extortion to me.
If you ask me to define what a *really* important server is, I would say 'Mine!'. Should I have to pay to get exploit information? I don't think so.
"Rocky Rococo, at your cervix!"
I would say this is hedging your bets. Essentially, once djbdns hits some penetration like bind did, you will start to see people exploiting it.
But you are right about one thing.. diversity is good.
Pan
I said no... but I missed and it came out yes.
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.
I work for a large ISP and we currently have an exploit that works on the latest versions of Bind 4 and 8. We obtained it when we were compromised and have decided not to share it. It's not one that is widely used by script kiddies and I tracked down and communicated with its author. I don't think Bind 4 or 8 will ever be secure do to the way they were written.
if you pay money you are less likely to distribute it out, it also, in theory, should prevent the reeto lets-get-on-security-mailing-lists-for-free-so-we- can-get-exploits from signing up.
-- MrMud
I would hope that if they do go through with it, that people still publish to BugTraq before they notify ISC. This is a load.
Keep in mind that there is going to be overhead in
deciding who is qualified, processing the NDA's, and administering this list. The fee would also have to be high enough to cover the cost of the legal fees that they incur on the non-profits for which they waive it.
As for wether they should have this list, I am not sure. I personally believe it should stay completely open, then they wouldn't need all that adminstrative overhead
Yeah, except sendmail has viable alternatives, like postfix. djbdns is *not* a viable alternative because of its restrictive license.
A lot of readers are sure how you feel about this?
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.
I agree with your comments and I, also, am not sure this is a bad thing, but take your first paragraph and apply it to the company we all love to hate ;) I think the biggest problem here is that Windows is *so* widespread, when a bug breaks, it is immediately a major exploit waiting to happen.
When the latest NT Server bugs hit...
We'd be ALL over MS if they attempted something like this. I realize they are different markets, as a whole, but I would guess the average person who understands BIND is far more technically advanced than the average NT user. (Notice I said "average" in the previous sentence; please no flames...) And therefore are better equipped to take immediate action when a bug is discovered.
The biggest problem is that most people don't know who the good guys are. Are you sure that the latest member added to the member's only list isn't White Hat Admin during the day and the Mad Cracker at night? In addition, if something goes wrong are the good guys opened up to liability? What happened is a Cracker takes advantage of a bug that has been disclosed in the member's only list (whether the Cracker discovered it independently or through a leak from a member). If a lot of money is lost, there is going to be a hell of a lot of blame being thrown around. At least now everyone is responsible for themselves...
Waltz, nymph, for quick jigs vex Bud.
Presumably, the requirement for information security training should help some with this problem.
Look, you are responding to an argument which I did not make -- That this whole scheme is a totally good and secure thing. I was responding to your direct assertion that "Some Crackers will crack there[sic] way into the mail spool..." That is the most direct attack to make, since it is pretty easy to determine where the spool resides.
Encryption removes this easy step and weakens, not eliminates, your overall argument. With encrypted mail, the cracker must determine the machine with the mail spool, then determine what machine holds the target's key, then root that box and either break the encryption or hope that the target is sloppy with his key or leaves the emails lying around unencrypted. This significantly increases an attacker's workload and opportunities for detection.
I will leave the debate over whether the whole scheme is a good idea or not to other threads. My argument does not take sides on that issue, and I do not care to hash over it. The system is not bullet proof, but it is certainly not as easily attacked as you suggest in your original message. Your post implied low hanging fruit; there is fruit there, but it is not as easy to get to as you implied. That was my point.
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
I've also noticed the "required" reboots that you can do without. But still... Check the uptimes here: http://uptime.netcraft.com/up/today/requested.html ... How many three digit numbers do you see for WinXX?.. no more comments.. :)
--
"No se rinde el gallo rojo, sólo cuando ya está muerto."
$HOME is where the
-- silver_p
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?
--
As a general Geek who regularly screws around with things such as BIND and DNS servers, I can't for the life of me comprehend how something like this could possibly be BENIFICIAL.
I know the reasons for it, prevents massive waves of "cyber-crime" when a hole is discovered and announced, but it's completely absurd that I can't be made aware of security holes in something simply because I'm not "important" enough to them.
If someone would define a C with decent string handling, and a few decent parsing tools, that would be a much better solution.
Also, the program stack should be divided among several stacks as far as possible.
I'm still trying to figure out what people mean by 'social skills' here.
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?
I program mostly in ASM and I'm not sure how a non-stack buffer overflow could lead to compromised security. At worst in .data or .bss, some data gets trashed. A variable-length buffer on the stack is an unspeakable evil.
Variable-length buffers ought to be malloc()d, but I guess foo(){char buff[80] is too easy to do. That makes char[] local and on the stack! Storing arrays on the stack takes up too much space.
Perhaps `c` should be re-spec'd to do a local malloc() on procedure entry and a free() on exit for arrays. Hidden compiler calls.
It doesn't matter how many times you rewrite the same shit, you'll still have bugs. The only way to "fix" BIND is to write the whole damned thing with security in mind and then stop grafting diseases onto it (read: buggy feature after buggy feature.)
All complex software has bugs. All software that interacts with untrusted agents most likely has at least one "buffer overflow" problem. Even perl has enough sense to force you to deal with tainted input.
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.
It got taken over by the likes of ICANN.
Hmm, maybe that's another good argument against this.
Fortran, LISP, Algol, PL/I, Ada
I think various compilers for these use no C or Assembly.
Qmail (same author as djb) has achieved significant penetration into the SMTP server market, and there have so far been no security holes found in qmail. DJB has a track record of writing secure code. The BIND authors do not.
Now who's going to leak to who? Are we going to get a hardcore of script kiddies with this inside information before the netadmins know about it? This would appear to multiply the problem rather than reduce it.
I really believe this mechanism has too much potential for abuse. Security through obscurity is often argued against, but people here seem to be forgetting the principle and saying that maybe it's OK for this one instance. I'm not sure it is.
I didn't pay for my operating system either
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?
Tell me about it...one small remark yesterday and immediately a buch of zealots and trolls jump on top of it to bash each other's heads in...
People replying to my sig annoy me. That's why I change it all the time.
When was the last time that a root or TLD server was compromised. Seems that given the past history of BIND, most root/TLD server operators operate in the paranoid mode. I think this really makes the root or TLD server ops finding out about the exploit first irrelevent since it is mostly the ISP level and below users of BIND that would suffer the most.
What is pirate software? Software for inventory of stolen treasure?
This seems backwards to me. If a security break is involved then the folks who found the hole already know what it is. The 'bad guys' already know about it. There is no additional safety in not publishing.
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.
I can understand where they are coming from. There was wayyyy too much general public coverage of the bug in BIND. When you go to foxnews.com and the major headline is a bug in BIND, then something has gotten out of whack. It's like leaving your house unlocked and putting a big sign in your yard to let everyone know about it. All the script kiddies who didn't know about the security hole, surely knew after the major news services picked it up. Something needs to change, but I'm not sure if this is the right approach to take.
Beyond that, it's not the language that's to blame. I'm running an mta and nameserver that's guaranteed to have no root-level compromises, and (as far as I know) has never encountered a buffer overflow. You know why? Sound design.
qmail and djbdns are proof that the language is not to blame.
Ideology breeds Hypocrisy. Just how much is up to you.
There has been a lot of discussion on Bugtraq about "How much time do I give the vendor to fix his bug(s)?". The answers are different depending on who you talk to about it but that's not the point. The point is that a lot of bug-trackers send their discovery to bugtraq FIRST without notifying the vendor at all. Sometimes, an exploit is right around the corner
Believe it or not, it can take quite some time, especially if the vendor / author is under the (wrong) impression that the bug isn't well known yet. In that time, all the users of the product are vulnerable. When frustration comes at it's peak, there is no better way to tell the vendor to hurry up then posting the bug to a good security mailing list. I am not making that stuff up, it happens every week on Bugtraq.
Considering all this, I think P. Vixie has made a wrong move. I understand 100% why he wants to do what he is planning on doing but I just don't believe it will work. Take my word for it.
Dood
Looking for a great online backup: Green Backup
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."
I think everybody is missing a step in the process. If I discover a new security problem with BIND, or any other software for that matter, that knowledge is mine to do with what I choose. Kinda like a copyrwite to a GPL issue. If I think that these security experts are the only ones I can trust to patch the problem and I trust them to be responsiable etc... I can choose to contribute to the closed source security pool. It's my right. OTOH if I decide to shout the security problem at the top of my lungs for the whole world to hear, that also is my right. I also think that security by obscurity does not work and any effort to put Pandora out of sight is going to fail. C and C++ are bad languages to do security right, I've read. Instead of havening Theo, et al, review the code for security flaws, 'somebody' ought to make the languages do security RIGHT by default so that programmers can't do it WRONG. But that will never happen.
zenray
wasn't there a movie with a running joke about 'i don't know what to think, please tell me'?
"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
What's to stop the hackers, crackers, and script kiddies from finding a way onto the mailing lists?
UNIX: Find it, fsck it, forget it.
-Benjamin Franklin
"Laugh and the world laughs with you. Cry and I'll give you somethin' to cry about!"
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.
Oh wait, wasnt that already done? How hard can it be to implement such a simple protocol? Even Microsofts SQL server is fairly secure.
As the Open Source Movement(tm) has shown, the community will likely prove to be more efficient in finding and fixing bugs than this group will. It's that whole mental distributed processing thing. Hopefully, they'll just end up looking like a bunch of lames.
"Ummmm..."
>if the script kiddies are more on the ball than the admins are, they deserve to get hit
;-)
Time to be a grammar nitpick and be modded down (an probably be flamed for some grammar/spelling error in my own post)
'they' in your sentence would refer to 'kiddies', not admins as you seem to have intended.
--
the script kiddies...deserve to get hit
--
you might have said:
If the admins are less on the ball than the script kiddies, they deserve to get hit.
...ahh, now I feel better. I've done my anal-retentive useless nitpick for the day and can now get on with the rest of my day.
There is much cruelty in the universe, John.
Yeah, we seem to have the tour map.
Qué?
--
when everyone gives everything,
when everyone gives everything, then everyone everything will get
...is to hide.
If they want to centralize kontrol of who has access... then it's no longer open source, correct?
This looks like another attempt to be exclusive based on "security concerns". If successful (which I doubt) then it would be a very convenient lever to use for the purpose of upstream content filtering (once no one except the exclusive handful is allowed to see the inner workings of the code).
It goes like this; "Hey, I got an unable to locate server error. Guess the site doesn't exist anymore." and "Hey, my Konspiracy Kracker web site isn't getting any hits. Guess no one is interested."
Then again, I'm not technical... just paranoid.
-The Government _owns_ your body...
Maybe this could be a way for hackers to make money. Hey, I found an overflow problem in Bind, send me money and I will tell you what it is. Oh, wait.... That's what they're doing isn't it. Never mind.
Sendmail also has a viable alternative in DJB's qmail.
The license is not *that* bad. Sure it's not GPL, but I don't find it particularly restrictive for the average user. Basically DJB wants to ensure that his packages maintain their integrity when redistributed.
If you read up on Dan, you'll see that he firmly believes that software licences and law allow for a user to modify the code as they wish. See http://cr.yp.to/softwarelaw.html.
So you can't bundle up your changes and redistribute - big deal. Just release your patch and let others apply as they wish. Happens all the time with qmail.
let them have their club, all of us "non-members" can have ours
--
Second, the idea of holding off announcing the bug until the patch is released is the same tactic we complain about Microsoft using. What if the patch takes two months, or longer? How upset would we be then?
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 wonder what affect a strong NDA would have on members communications to the press when punks are terrorizing the web. The exploit spreads like wildfire, but members would still keep mum. "What exactly is the H4X0r doing?" "I'm not allowed to say." "Rumor has it he just presses the Windows key at the wrong time." "No comment." "What kind of countermeasures can we use." "Sorry, I'm not allowed to disclose that to non-members." "When will you have a fix." "Once all members have implemented their fix and signed off." "MegaCorp says they have a fix." "I cannot comment on excumunicated members' press releases."
-- the most controversial site on the Web
I remember when some of the early e-mail worms came out that attacked Microsoft Outlook (it's so easy, isn't it?) by sending mail to like the first 50 people in an address book. One of the news stories that annoyed me the most was hearing about a "secret" network of system administrators that worked for banks and financial institutions who were notified days in advance of the rest of the world about the problem. I don't know what "notified" means, but the situation sounds similar. I was plenty pissed off when my systems were affected before I knew about the problem. And I was hooked up about as well as could be to "normal" security info centers/mailing lists/whatever.
These things should be made public knowledge ASAP. If Bind decides to notify some root servers an hour before they make a general announcement, then that's their perogative, but the idea that information would be passed around there that would never make it to the public is bad mojo. A separate mailing list would make that more likely, even if it isn't intentional.
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
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++?
Isn't the Linux kernal written in C/C++? And most of OpenBSD? And TrustedBSD? etc etc. You have some disdain for "C/C++ hackers" but there are also a number of C/C++ professional software engineers.
How on earth did this get moderated up when is just a rehash of the old BIND argument with absolutely nothing new to say?
I'm not going to repeat the same arguments *again*.
Phillip.
Property for sale in Nice, France
I'm not sure how I feel about this, but I'm sure a lot of readers do.
Typical of a slashdot story. Someone submits a link and makes a comment on it, but waters their comment down, either removing technical commentary or opinion, so that they don't have to take any stance. Thus, they cannot be "wrong."
Show some backbone and say that you think it's a bad idea to restrict access to BIND Security Info.
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
'Keeping out the riff-raff' so to speak.
My initial reaction was indeed: What the fuck? We deserve the info, for free!
But reading your contribution I realised: Perhaps Vixie wants a little extra barrier to keep the script kiddies from getting the info and acting upon it, before us hard-worked sysadmins have time to plug all the holes on all the systems they manage in all the world. Hence the suggestion of "strong" non-disclosure agreements.
Sadly, it won't work. There is no guarantee that some patron script-kiddie-hero-wannabee won't have the dosh and the position, to be a member of the the list, or that simply some disgruntled sysadmin won't leak the info to the kiddies (or won't be one), or that the info will not be found by a hacking kiddie from hell.
We manage a fair number of servers and there is no way we can ever keep their security ahead of the kiddies. We do our best, but I'm always sure there is always a hole somewhere, I just hope and pray we find it and close it before they do. Usually they overlook us and our customers, no media attention in it. So only jail, no glory.
But no matter what you do, security through obscurity won't work even the way Vixie proposes. That's what I think. Information leaks, almost as if it wants to be free.
Stefan.
It takes a lot of brains to enjoy satire, humor and wit-
The truth shall make you fret. (Ankh-Morpork tImes motto)
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.
Won't it be an even bigger headache when you get cracked because you were using insecure software?
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
"root/TLD nameserver operators, software vendors using BIND, and 'other qualified parties,'" What always gets me is what is "other qualified parties".. My company doesn't make software, we're not a .com, and we are not high tech.. we do construction. Damn, I'm not qualified. OK, I've got two Sun Enterprise servers and upwards of 16 NT servers.. and these are not little workgroup servers.. BIND is on both OS's. I've got Six (6) offices in the US and Two (2) overseas.. plus vendors that we interact with in another dozen locations. I always love that since we do construction, were not qualified.. cause hey its not like anybody would ever try to hack us, or DoS our boxes.. so who is it that decides qualification. And who says that a Tier 1 ISP that is "qualified" doesn't employ the script kiddies this is trying to prevent from getting the info..
hahahaha... you make me laugh. As if VB or Java is going to be more secure?? Ohh sure... there's the possibility that they may be less suceptible to buffer overflows.. (Maybe? who's to REALLY say until it has 20 years of history begind it like C)
It's not just the language... it's the LOGIC.
Good programmers think LOGICALLY... processes are LOGICAL. Data is build on trusted logical assumprions and sources.
Otherwise, you have poop.
Pan
I said no... but I missed and it came out yes.
Hear, hear! Folks, if you write C++, learn the STL (which is now part of the language itself).
Unfortunately, in practice most C++ developers write code that is nearly indistinguishable from C. Hence the never-ending stream of new buffer overflow exploits.
-- Brian
The most rabid believers in American Exceptionalism are the exact same people whose policies are destroying it.
Giving vendors a little jump on the crackers makes some sense.
Vendors, yes. But what about the rest of us? Pseudo security through enforced obscurity might make sense in an environment where end users and admins have no ability to alter or repair their systems by themselves (i.e. Microsoft) and are forced to wait for patches from 'on high'. But that is not how open source software works, and is one of its major strengths. Reducing competent admins access to security warnings, even for a little while, does nothing more than reduce us to the same status as those poor schmucks that have chained themselves to Redmond.
The concept behind this closed access security model (even if its only temporarily closed) assumes that bugs will be discovered by the white hat 'security community' before they are discovered by the black hat 'cracking community'. With open source software, that cannot be the guaranteed. Especially with the bugs that keep popping up in BIND (sprintf buffer overflows == stupid stupid stupid). What happens when a cracker discovers a hole before Vixie and his anointed? And then the cracker writes a kiddie script for it?
I can only see that this benefits vendors, big DNS admins, and the few other people deemed worthy of being on the list. We little guys are still on our own.
Right now, whenever a security hole is announced, the first thing I do is check my box and try to plug the hole myself. At the very least, I make sure to back everything up. Then, when the official patch comes out, I check it out and replace my fix. Anyone concerned with security doesn't have the luxury of waiting on the convenience of their software vendor.
What Vixie is proposing would limit you to one of three ways of finding and fixing security holes.
Only one choice is a good one, but you don't get to choose which one you actualy get.
Many of the security holes in BIND thus far have been temporarily pluggable simply by turning off the affected features until a patch is released. Waiting with our servers hanging out for the patch to become available simply because we aren't made aware of these small temporary fixes is not secure. Besides that, many of the BIND induced security breaches occurred after patches were available simply because lazy admins did not bother to install the existing patches (and thereby deserved what they got).
For best security, I need to know about holes as soon as possible so I can try to fix them myself before any attack. Giving vendors the 'feel good' ability to announce security holes at the same time they announce fixes is not worth my security. If Vixie goes through with this plan, I have no option but to find an alternative to BIND (if there is such a thing).
To badly paraphrase Dune:
The first step to avoiding a security hole is knowing of its existence
Let me get this straight. Some of you are willing to tie up your nuts in an NDA to keep using spaghetti code just because it's GPL (or because "everybody" else is using it)? Isn't this the same crowd who jumped the Windows ship for Linux?
Why are so many of you so desperately clinging to something so flawed when something so obviously superior can make your lives easier? Which do you value more: the GPL or your own happiness? Jeez, some of you remind me of the People's Front of Judea Suicide Squad (or was that the Judean People's Front?).
At least take a look at djbdns. Think about these questions as you do. How the hell can you crack it? What of value does the license actually prevent you from doing; and of how much value is that really? Why would a multi-million dollar organization use BIND instead? What love should they have for the GPL? Why would any BIND administrator get to keep his job after getting cracked, when he could have been using djbdns? Why would BIND improve if it didn't face the threat of extinction for its sins? How many assholes are among your favorite artists? Scientists? Businessmen? Why have you not thrown out their work with their party invitation?
Get your head out of your ass and choose something that actually does what it's supposed to do, without holes!
-B...
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.
You are correct.. in the short history of qmail, there have been no security holes.
But the authors of BIND had no concern of hackers when it was originally written. Hindsight is always clearer than forsight.
But BIND is here.. it IS working day in and day out. Problems are serious, but it is working well for the vast majority of users.
I have no doubt that DJB is a good programmer... and I fully advocate good diversity. But don't advocate the casual trashing of BIND. It is the rock on which we build the internet.
Pan
I said no... but I missed and it came out yes.
CmdrTaco
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
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.
"Pointer clobbering" may be the cause of many an access violation, but I've not seen any exploits based on it. Do you know of any?
-- Brian
The most rabid believers in American Exceptionalism are the exact same people whose policies are destroying it.
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 doesn't matter how many NDAs you have people sign or how private the list. c0re digest was being read by people who hacked the systems of the list members! This is a common occurence on "closed" security lists.
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.
==
Using different DNS BIND implementations,
==
That's one of the problems, there are really only a couple of credible named implementations. It's not like there is a wide choice, it's pretty much either BIND or DJB-DNS.
maru
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.
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.
maru
If you have a very important piece of software, and you're worried about bugs and exploits, keeping an NDA list of security problems isn't going to help. Anyone who knows about cracking knows that breakin techniques pass as much by word-of-mouth as they do by an email list or web site. What you need is not to hide the bugs; you need to eliminate them in the first place. I'm sure most readers are familiar with TeX, and its virtually bug-free state. It got that way through a well thought-out design, extremely well documented code, and verification proofs. So what we need is for people to use the same techniques as Knuth used in TeX to write replacements for vital internet functions. It will take longer and offer less features than hack-and-go code, but if it's really that important you can afford the extra time and cost. Remember: software can be fast, cheap, or correct. Pick two of three.
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
Although it sounds good on the surface, I don't think it follows the tenets of open source development. I for one like to also hear about the security holes so they can be fixed as soon as they are found.
"FORMAT C:" - Kills bugs dead!
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.
This whole thing stinks. I found an exploit, I am the only one who knows. Yea right. The fact is many people may already know and be using it right now. Get the information out. If ISV can not keep up, they need to go into another line of work. Everyone needs to know asap.
Eventually they have to release some information about the bugs. The fact that the bugs have been discovered means that some cracker is going to find them too. Instead of hearing about the bugs in the bind-announce we're going to hear about it on the 8uGz-t0-3Xpl01+ list. ------ ISC has historically depended upon the "bind-workers" mailing list, and CERT advisories, to notify vendors of potential or actual security flaws in its BIND package. Recent events have very clearly shown that there is a need for a fee-based membership forum consisting only of: ------ What are those recent events? Reached the last check in your checkbook? A private list and a fee based list are mutually exclusive ------ 1. ISC itself 2. Vendors who include BIND in their products 3. Root and TLD name server operators 4. Other qualified parties (at ISC's discretion) ------ 5. Anyone with $$$ and can either fake being a corporate d00D or is in a corporation and has contacts to the cracker community. ------ Requirements of bind-members will be: 1. Not-for-profit members can have their fees waived 2. Use of PGP (or possibly S/MIME) will be mandatory 3. Members will receive information security training 4. Members will sign strong nondisclosure agreements ------ This exclusion of everyone else using BIND is a betrayal of anyone in the common user community who has ever worked to look over that code and found bugs or a way to improve the code. ------ Features and benefits of "bind-members" status will include: 1. Private access to the CVS pool where bind4, bind8 and bind9 live 2. Reception of early warnings of security or other important flaws 3. Periodic in-person meetings, probably at IETF's conference sites 4. Participation on the bind-members mailing list ------ Stupid, stupid, stupid. Eventually the bugs will circulate by word of mouth (no NDA can stop it) and the bugs will be exploited while everyone else who holds that NDA as holy will stand by and watch as sites get hosed instead of passing out known info. I don't know if you're trying to create some monastic order of name providers, but this has to be extremely stupid and goes against the whole idea of the internet in spreading information. The responsibility of sites having trouble when a bug is discovered lies with the admins if a better version is out there. The flow of information is essential; keeping admins ignorant is wrong, and charging a fee for the information is holding us hostage. Will the code eventually be hidden from common users for a year while the brotherhood of named gets the latest fixes? Maybe only binary versions with backdoors in them will then be available. See this as the beginning of mistrust. ------ If you are a BIND vendor, root or TLD server operator, or other interested party, I urge you to seek management approval for entry into this forum, and then either contact, or have a responsible party contact, isc-info@isc.org. Paul Vixie Chairman ISC
"Beware of he who would deny you access to information, for in his heart, he dreams himself your master."
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.
What do people make of this comment for "ISC members":
Features and benefits of "bind-members" status will include:
>
> 1. Private access to the CVS pool where bind4, bind8 and bind9 live
>
PRIVATE access?? Does this imply "EXCLUSIVE" private access?
what the heck is Paul talking about
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
www.suse.com - Linux - 247
www.etoys.com - Linux - 157
www.zdnet.com - Solars - 218
slashdot.org - Linux - 240 (mentioned twice)
www.yahoo.co.jp - FreeBSD - 342
billgates.com - Solaris - 159
www.aol.com - Solaris - 389
www.bbc.co.uk - Solaris - 282
www.google.com - Linux - 163
Those are just the 150+ max times. As well, I only count five FreeBSD entries in that list of fifty. I'd say Linux has a decent showing for long uptimes, but if any were to be said "the major majority," it would have to be Solaris.
Ah, okay. Well, thankfully we can qualitatively
rate humans on how much money they have and are
willing to spend.
BIND is bloatware, in most cases tinydns by djb would be more than sufficient, it's faster, smaller and much more robust and secure, especially due to the size of the code. So screw Paul and screw BIND.
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.
There's no substiture for good code ( a good coder ).
;)
There's plenty of examples where good coders have done great jobs in C, Qmail, djbdns, BSD lib c, and so on.. so how about we teach programmers better programming? how about we start making and enforcing wrapper libraries like safe string?
I'll be nice so easily switch to so called " safer " languages.. but that won't happen in the real world...
just my 2 nickels
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)
This is going to cause problems. Bind security details will become details known by two groups of people, the people who need to know or the world will fall apart, and the people who they people who need to know want to not know. that make sense?
Spring is here. Don't believe me, look outside!
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.
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.
What would be ideal is if the NDA's had a time limit, say 21 days from initial discovery, during which the list remained quiet and worked on a fix, and then on the 22nd day the NDA *required* the members to all divulge the news, say on their respective web sites. That way, the leader of the group is not put into a position of having to divulge the news and embarrass one of it's own members; they all do it together without choice.
I think this group should also think about the number of days that is required for silence and put a limit on it from the beginning. There should be one mechanism for an extension of a fixed amount, and that's it. No member should be able to drag out the process. In any case, the news should be public within 30-45 days MAX.
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!
"What up" with all the redundant moderation around here lately? When I replied to this story, there were only a few comments posted, none about djbdns. I spent a few minutes researching my claim that there are no known exploits for this software and unbeknownst to me, others have posted similar comments to the story already.
I've seen a lot of folks making good comments getting screwed by moderators on this lately. Wake up folks, Slashdot gets a ton of traffic these days and there's no reason to penalize folks who don't get "first post".
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.
What languages exist that weren't created in C, C++ or Assembly? At the end of the day, avoiding things written in C/C++ or Assembly, languages or whatever, is rather difficult to do.
Regarding letting the compiler do the work, with regard to this subject, that's not a complete solution either. No matter how good a language or compiler is at preventing these kind of problems, it's not going to prevent a programmer from coding something that's just plain wrong and creating some kind of exploit. Whenever humans are involved, mistakes will happen.
Sensual: Running a feather down your lover's body
Kinky: Using the whole chicken
It's a very dark ride.
That might be 47 hours too late for your nameserver, eh? BIND is one of those Bugtraq all-stars, making early notification of it's users all the more important.
itachi
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
Yep. And try telling people that, too! They start flipping out and arguing with all sorts of pitiful excuses. It's really irritating.
--------
Genius dies of the same blow that destroys liberty.
I'm on the bind-users mailing list, and here are some of my comments:
Date: Wed, 31 Jan 2001 20:39:35 -0500 (EST)
From: Jeffrey C. Albro
To: bind-users@isc.org
Subject: Re: PRE-ANNOUNCEMENT: BIND-Members Forum
On Wed, 31 Jan 2001, Cricket Liu wrote:
> > This is not an open source but a full/partial disclosure issue.
>
> No, it's not. No one is arguing that the vulnerabilities shouldn't
> be disclosed and disclosed fully. The question is when.
I agree. However, the "when" part needs to be laid out MUCH more
clearly. If a vulnerability is found on the first of the month, and the
main bind tree is patched by the seventh of the month, how long do you
wait for vendors to patch their (assuming they have forked to some
extent) version? To the 14th of the month? How long will a viable fix of
the main source tree be held in secret?
> Surely you can understand the need to patch critical pieces of
> infrastructure such as the root, gTLD and ccTLD name servers
> and to prepare patched binaries of BIND for various operating
> systems before the vulnerability becomes widely known.
Of course. But how long do you give downstream developers? Do you give
them N days, and when N+1 appears will the forum embarrass paying members
of your group? If everyone signs an NDA, no-one can squeal. Can a time
limit be put on the NDAs?
I believe this idea can help solve security problems faster, with less
advertisement of the exploit, but steps need to be taken to make sure that
is actually what happens.
How is the conflict of interest solved?
-Jeff
>
> cricket
>
>
>
I agree with you, but I think the parent poster was referring to languages like Python, not VB or Java.
What we really need is a C library with no strpy(), gets(), etc. A mostly or completely redesigned C library would be nice.
--------
Genius dies of the same blow that destroys liberty.
- Lazy/hasty coders
- Stupid (or very inexperienced) coders
Language isn't one of them.bla
I think you guys are missing it just a little...
It's not usuallly the people maintaining bind who find the bugs.. it's the regular users. When someone finds a bug, they may wish to report it to a malicious party instead of the project maintainers. Which would be very bad too... So people are going around exploiting bugs way before anyone realizes they are bugs.
Just my $.02 as well
If the list automatically forward the messages "outside" after 48 hours, I would have no complaints.
--------
Genius dies of the same blow that destroys liberty.
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.
How about 48 hours?
--------
Genius dies of the same blow that destroys liberty.
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
Yes I linked to the most requested sites because those sites are the ones people are interested of. I for example don't recognise a single site from this list... exept www.rms.org which wasn't what I thought.. ;) .. nevertheless, it's an interesting read.
--
"No se rinde el gallo rojo, sólo cuando ya está muerto."
$HOME is where the
-- silver_p
Old benchmarks, perhaps? Some tests show that using standard library template classes (not the same thing as the STL, which is a specific implementation) instead of C idioms is a win in some places and a loss in others.
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.
Would you see a problem with this if all mail traffic was forwarded to anyone who wants it after 48 hours? I don't.
--------
Genius dies of the same blow that destroys liberty.
What about if all list traffic is automatically forwarded "out" after 48 hours? Then they still have to bust their heads to fix the bug, but they get the time they need before a rootkit comes out.
--------
Genius dies of the same blow that destroys liberty.
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
Huge numbers of people operate their own domains, and I suspect that Mr Script kiddie will just set up a domain so he can be kept on the info list.
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
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...
to get anal...
the first "I'm" (the subject) indicates that the speaker is not aware of the feelings which the recipient - "I", in this case, possess, but that the "readers" are aware of that.
thus, it would seem that we have a firmer grasp on the way that taco feels than he does.
We who were living are now dying
With a little patience
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
Using BIND hasn't saved me any headaches. That was the whole point of my diatribe :-)
Sendmail is in a nice, easy package, too...
Having a database backend and the tools to modify the data file do indeed make it all easy, and pretty damn painless. That means with some sanity checking I can let others around here do some of that work.
Like many things worthwile, it just takes some work and motivation. I was personally highly motivated.
OT: All my handguns don't have safeties, and I like it that way! (sigsauers)
(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
Full disclosure is important, "MS Product" or not. Obviously Bind is critical software, but what's next? A pay-only, gag-ordered Linux kernel security group? Apache issuing statments like "new security vulnerability discovered... information available in 2 weeks"?
A private, NDA'ed 'club' for TLD admins is not going to save Bind from security issues. It will do no good if Joe Haxor is 'auditing' code at 3am and finds a new bug. It will do no good when Bob Sysadmin finds a security hole, unless he decides to submit to this closed information flow and tell no one else.
Most of all, what if my cousin or your neighbor can write a patch in an hour, whereas the Bind Club sits on it, with its limited membership, until a week later when the exploit is already publicized and being used en masse by scriptkiddies? I'd choose any number of people in the Open Source community over Paul Vixie and company to entrust the security of my nameserver to. Harried sysadmins need to know where the security faults lie, if nothing else.
The answer, once again, is obviously not simply muting security warnings, particularly if the flaw is being exploited in the field.
The problem here is not the flow of security and bug information, but the existence of unaudited, unfixed security holes.
In the end, this is only going to exclude some incredibly valuable folks who could be doing a much better job at auditing and patching the code. Neither will it do anything to slow down bugtraq postings, which frequently originate from attacks or information coming from the cracker realm.
I'm not sure, but I know for a fact that it's open source of one kind or another.
How about a modification or a sublicense of the GPL that specifies that security information may not be shared privately? GPL Experts?
The next Slashdot story will be ready soon, but subscribers can beat the rush and slashdot the links early!
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.
Um, how about if we just fix the security bugs in BIND instead?
For servers that don't need full-blown BIND authoritative name resolution, dnscache is a great way to get caching name service with minimal configuration to get it up and running.
It is possible to run dnscache without daemontools.
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
So whos to say a network administrator will obide by the oath of silence? What if (and im sure this never happens...) an administrator doubles as someone who dabbles in others security. Then not only is he securing his network quickly, he's also got access to others, and no one has any idea. I say stick with the open sharing of recognized security flaws.
~ Chris
ObliTech Consulting
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
djbdns is NOT a viable alternative to BIND IMHO. It has no support for many of the emerging standards like DNSSEC, dynamic DNS, integration with Microsoft Active Directory, etc. So yes, if all you're planning on doing is serving up static names on port 53 (udp only of course since he apparently doesn't believe a DNS packet should ever be larger than 512 bytes) then use djbdns. The rest of us have to deal with a real world where people ARE looking to implement these new technologies and they are damned nifty.
IIRC posting an encrypted message to a mailing list requires everyone on that mailing list to have the corresponding decryption key. If somebody on the list is compromised, chances are pretty good the intruder will be able to locate that key one way or another - perhaps as clear text in an initial "welcome aboard" email?
Using PGP would probably be most effective at preventing a cracker forging a message to the list, I am not sure I see it as protecting the list.
Education is a better safeguard of liberty than a standing army.
Edward Everett (1794 - 1865)
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.
It think this is important. Security people are aware of string buffer overflows now, so escapement hacks will be the next wave.
A test facility should be included.
I'm still trying to figure out what people mean by 'social skills' here.
I'd like to know why in the blazes "members" should be the only people getting the early warnings on security issues. Seriously here, if they wanted to close the source yippee for them, knock yourselves out, but why restrict the security warnings, all it's going to do, IMHO, is cause admins to find a different solution that doesn't require BIND...
Which sounds better the more I think about it anyway...
Plead sanity, then they'll know you're crazy...
Perhaps someone should recommend evaluating whether BIND is still the best choice for TLD providers. It isn't the only game in town and after all, wouldn't someone be able to create a better piece of software anyway? I'm sticking by my "just say no to BIND" policy on my network...
... 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."
If the idea is to keep the "dangerous" info from the general public and script kiddies, and thereby make the internet less vulnerable to attacks, they are barking you the wrong tree. The good sys admins keep up on this kind of stuff and close the holes within a day, if not a couple of hours of finding out about security issues. The lazy ones let it go for weeks/months and they get hit by 31337 H4X0RS. My point is, even months after an exploit is commonly known, people still haven't patched to fix it. Giving a few days extra notice won't help.
There are 01 kinds of cars in the world. The General Lee, and everything else.
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.
"Qualified Parties is that part of this which worries me, who is going to decide who is or isn't a qualified party? I co-admin two boxes which act as both primary and secondary DNS for several domains, would I qualify? I don't work for a company and have no offical status as a DNS admin other than having root access to the boxes.
If I (we) have to find out about the security problems by chinese-whispers, or even worse, our system actually being comprimised becuase of it, it isn't going to be good, for us, or for BINDs reputation.
--
Yeah, I had a sig once; I got bored of it.
I think DJB understands the unix philosophy more than even a lot of the oldschoolers like vixie.
In any case, it's a lot easier to write a secure program from scratch with security in mind than it is to take a huge monolithic program without a single concern for security and make it secure.
God, I hope you don't have children..
Score:-1, Pompous
Even if it were a good idea to get to `security thru obscurity' (and it isn't), the most important thing here is that the bind people want to make some money out of it. It is weird, the last time I checked, bind was free (and reasonably free, like with no weird installation clauses a la djb like tinydns and friends). Wow, this reminds me of something... let me think. Yes, they are trying to pull a X consortium on us, aren't they ? I mean, you start with a free bind, then you discuss crucial steps of development on a private list (the `membership waved for free projects' is such a blatant suck-up move I don't believe anyone will fall for that), and pretty soon, you end up with something similar to the initial license to X11R6.4. Well, it is way past time to build some new DNS tools that work and are truely free anyways...
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.
I'm a leaf on the wind. Watch how I soar.
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..
But no language stops you from writing brain dead code...
It still takes good programing practice to write safely
Advanced users are users too!
My question is simply how do they plan to really maintain a 'private' forum for this...? Is it feasible that they several hundred (several thousand?) people can know about something and it not leak out? Or, can that many people exchange information and not be "overheard"?
If liberty means anything at all, it means the right to tell people what they do not want to hear. -- George Orwell
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...
Oh no! I hadn't thought of that before. I guess I'm going to have to... take steps...
--
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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.
That is one of the better ideas I've yet heard on /.
Setting it so that any post to that 'private' forum is reposted publicly in 30 days is an excellent idea -- but it would be important that the 30 day time limit be absolutely enforced and not revocable for 'just a little more time to fix bug X'. IE, short of the whole internet crashing, at 31+ days the entire world would be able to read any post/message to that list.
That seems fair and reasonable -- as long as it is ironclad.
I'm tired of dealing with the root exploit de jour. I'm switching our nameservers to djbdns. It's ightweight, fast, stripped-down, and (presumably) more secure than BIND. At least, I've yet to see an exploit for djbdns.
Paul should remember his time at DEC, where restricting security information was business practice. Remember VMS? How secure that was....
Can anybody else get their upgrade? FTP server seems to be down. How long have the new tarballs be unavailable because of this? Anyone know if it's just the usual "oops" or is it throttling connections due to high demand?
Edith Keeler Must Die
The simple fact that qmail has been exploitable (DoS, not permissions elevation) in the past invalidates the majority of your arguments.
maru
D. J. Bernstein claimed that his program should do the security tricks much better than bind, how many of you agree with me?
Don't be a moron. The guns don't have built in safeties, but I keep them locked up (ie. gun safe)
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.
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 doubt if you will find exploits in djbdns. Given the quality of djb's other software like qmail, there aren't any exploits.
What is pirate software? Software for inventory of stolen treasure?
bind to my root now! You young whippersnappers!
Strom Thurmond; the dean of the US Senate...
Strom Thurmond; the dean of the US Senate...
the deadest fart on slashdot.
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.
That's not what I'm talking about. I fear for the children of anyone who actually *prefers* or takes pride in the fact that their guns don't have safties on them. Not only is it macho bullshit, it's dangerous.
If it's macho not to have safties, wouldn't it be macho to keep one by your headboard, loaded, while you sleep? That's what my dad did.
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.
Sig Sauers have plenty of safety features, just not a 'safety'.
They have a hammer de-cocking lever (very nice), and a firing pin locking mechanism (so if the gun is dropped on the hammer, the firing pin won't move).
I don't understand your POV. If the gun is locked up, (my non-existant) children aren't going to be messing with it. If they've got their little untrained hands on a gun, its a little too late to hope for a traditional gun 'safety' to save the day.
However, I'm not alone in my 'macho' attitude, whatever that means. Lots of LEO and federal agencies prefer Sigs. They are one of the best brands out there.
Also, I do have a loaded handgun near my bed. However, its in a quick access gun safe, just big enough for one handgun.
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?
The ability to run BIND chroot'ed and/or as a non-privileged user after the bind() call has been available for some time now.
My ancestors evolved from primordial ooze, and all I got was this lousy Existential Angst!
That's funny!! I never need to deal with DJ. You know why? His stuff just works without these headaches!
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.
It's not like BIND holds the internet together or anything.
I adblock all animated gifs.
Blessed be the prime numbered slashdotters
All of the rest of us would not know of the security hole and being able to take precautions unless we join a closed group. No thanks.
Bind runs on root servers and TLD servers. If those don't work, *you* don't work. For a short period of time, many of them were vulnerable. It makes sense to give them at least a few hours advance notice to get them patched.
This won't stop the hard core crackers as they already know about these vulnerabilities in near real time. It will stop the script kiddies who lurk on Bugtraq.
--
*Condense fact from the vapor of nuance*
25: ten.knilrevlis@wkcuhc
*Condense fact from the vapor of nuance*
It seems to me that many security related patches are reactionary. Thus, why make a secret of what the bad guys already know, and the good guys wish they had?
There should be more DNS implementations: if there were a rich collection of nameservers out there, with "redundant" TLD's running different implementations, it would be a lot less likely that one buffer-overflow puts the whole internet at risk.
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.
If you had been taken to court by the federal government, and threatened with imprisonment for trying to teach your university classes, you might be a little paranoid too.
This is Daniel J. Bernstein, the fellow who won for everyone the relaxation of crypto export controls. Maybe give him a break.
--
Twoflower
That just works the best.......
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.
These days I think I read as many posts spouting against the Slashdot party line as in favor of it. Things are a lot more equitable these days. You're not just wrong if you're pro-MS; you're wrong if you're pro-anything.
--
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.
I think that the problem here is that the larger the list gets, the better chance that the bug/exploit/etc get leaked out and there is l33tbindhax0r.pl floating around the next day.
At the same time, if you keep most people off the list, less admins out there are actually aware of the problem, and there are less people that are actually working on a solution. At this point I think that the best solution might still be full disclosure. Yea, the problem gets exploited that much faster, but at least the solution gets out there pretty fast as well.
Mike
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.
IT IS COMPLETELY IMPOSSIBLE TO READ!
Not what I look for in code. His opinion is, "If you are an expert you can figure it out." Which is true. I can also extract the Java source from a .class file, but wouldn't it be nice to just have an easy-to-follow, commented source file?
Sure, it is probably safe, but how could you tell?
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
Who decides what 'other parties' are 'qualified'? Will they only allow large corporations that are running BIND for their name services to participate? Is a smaller web hosting company less deserving to be secure than UUnet?
djb's stuff is not a closed source binary, so yes others do look at his code. If Bind is so good then why is there new exploits every few months. Qmail,djbdns are not huge do everything programs, qmail,djbdns are made up of many smaller programs that do one thing and do it well. It was designed from the start to be secure unlike (cough, cough) bind and sendmail.
What is pirate software? Software for inventory of stolen treasure?
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?
Do you really think that even someone with the god-like (cough, cough) capabilities of Daniel Bernstein is capable of performing a similar review all on his own?
Good, I didn't think so either...
The announcement email indicates that sensitive communication will be encrypted:
Someone apparently got lost on their way to junior high this morning.
Perhaps BIND is tired of "Racing" against the clock to fix their worthless products.
Check out DJBDNS. It kicks bind's but and every line of code is custom. Even his string libraries are buffer overflow proof. But, even if it overflowed, DJBDNS does NOT RUN AS ROOT.
Why in the world would you need to run a simple database lookup utility as root? Get a clue bind, you're played out now...
-GG
Forget bind and Mr. Vixie's shenanigans -- get Dan Bernsteins awesome replacement: djbdns. You've heard of qmail and how famously reliable and secure it is, right? Well Dan's done the same thing with DNS as he's done with email. Anyone still running BIND on a authorative nameserver had really ought to consider switching. I did, and it's made my DNS life much much simpler.
..
Real soon now, we'll be releasing a management interface that plugs right into djbdns too -- http://dajoba.com/projects/nictool/
Abe
This group Paul is proposing is not an exclusive group in terms of who receives the upgrade/security alerts. Already, when a new version of BIND is ready for release, it is given to the ROOT server managers. Since the DNS heirarchy is no longer merely . and everything else, there need to be more clearcut ways to define who should receive the "early warning" (bad word to use, but take it lightly :).
"ISC wanted to get the new code on the street soon enough to give people a running head start at upgrading. (the root name servers were all done last week, for example.)" -- Paul
HTH
I've read several comments that seem to imply that since BIND is open source that all knowledge regarding bind should be Open also. I'm not sure I agree with this. I do not agree with the "security through obscurity" mindset. I work in the information security field and know that this is not good. But also being in this field I know that there are certain trade off's w/ everything. It can be very good for certain people to know about holes before they are released to the general public so that a fix can be prepared and in place. What good is telling the world that such and such app has a vulnerability without having fix for it!? Your'e just allowing alot of people to be worried at night wondering if some script kiddie is poking at their box looking for the newly announced unpatched vunerability. That being said...I beleive that this group should take responsibility to release the information to the public once a patch is created. Also...this does not mean that ALL information must pass through this group! Suppose I discover a new exploit. I'm not part of this member's only group and therefore am not bound by its rules and regulations. By creating this group they will inherently segregate themselves from a larger population willing to solve such issues. Just keep in mind that this is America..just becuase somebody doesn't agree with what they are doing does not mean that it is wrong. They have the right to segregate themselves...it's up to the open source community to hold them responsible for their actions...or is it...I don't seem to remember seeing any statement from ISC that bind is warrantied in any way..nor do I remember paying to use it...it is provided for free..if I don't like it's function or polotics I don't have to use it--but that is for you to decide! Just my incoherent .02c
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.
when i found out about that stupid bug, I spent most of the day in a panic that someone would hit one of the 7 nameservers that i'm responsable for before I could upgrade them.(all for high traffic sites that usually get about 2-3 "security" scans a day)
As such, I don't think I really have to much of a problem with it being released out to these "members" as long as I am one of them. (which is the ucky part). It should be released after about a week or so to the public, however.
-- MrMud
[fill in the blank]
> So, is it OK to do this in an attempt to give the good guys a jump on the bad guys?
It's generally accepted practice (tho by no means mandated) among security researchers that they give the exploited company 48-ish business hours to patch whatever exploit they find before releasing it into the open. As was the case with BIND, researchers can and have sat on major bugs with no workarounds for much longer periods at the developers' request.
So would you rather hear a company announcement or wait for CERT to alert everyone (maybe) or Johnny Q. Scriptmonkey to point out the fact that you've got a glaringly open hole that you didn't know existed and don't know how to fix?
Easy does it!
This comment has been submitted already, 276865 hours , 59 minutes ago. No need to try again.
..we wouldn't have a need for such a thing.
bind, dhcpd, cron. All out of that camp. All with an unreasonable history of security problems.
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.
Bah, we just need to have people use a library which "accidently" forgets to include stuff like strcpy() and strcat() and include this library in the distributions that people are using for servers. Then when they try to make, it fails to link and they fix the code. ;-)
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
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.
A "members only" idea scares me. You'd have to sign the non disclosure, and there is no telling what they will put in that. To top it off they could eventually require "membership dues" to "cover costs" associated with the membership. The dues then could set so high to eliminate everybody except the rich.
I don't like the idea.
At the next eco-hypocrisy-meeting, count the private jets used to get to the meeting. Should be interesting to see that