BIND Security Info For "Members Only"? 331
achurch writes: "Paul Vixie has posted a message to bind-announce suggesting the formation of a "members-only" security information list for BIND, the DNS server used on most Internet systems. Membership would be limited to root/TLD nameserver operators, software vendors using BIND, and 'other qualified parties,' and members would have to sign 'strong nondisclosure agreements.'" I'm not sure how I feel about this, but I'm sure a lot of readers do.
Re:It makes some sense (Score:2)
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
Re:This actually isn't a bad idea (Score:2)
This list won't do dick to stop exploits.
- A.P.
--
* CmdrTaco is an idiot.
Re:It makes some sense (Score:2)
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.
Re:Fights script kiddies (Score:2)
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.
--
Your thoughts (Score:3)
Re:how many more buffer overflows is it going to t (Score:4)
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.
--
Dumb Idea... (Score:2)
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.
Re:Use djbdns if you want security (Score:3)
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
Embargoes perhaps? (Score:2)
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.
Re:how many more buffer overflows is it going to t (Score:2)
I can kinda understand (Score:5)
BTW, first?
--
Slashdot in a sentence (Score:4)
Wow, that is Slashdot in a nutshell, isn't it?
Use djbdns if you want security (Score:4)
Re:My response.... (Score:3)
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.
They finaly realized (Score:2)
The only way to compete is to close the source and hide the bug list.
I wonder where they got the idea.
Who cares? (Score:2)
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?
Re:Fights script kiddies (Score:2)
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?
Re:how many more buffer overflows is it going to t (Score:2)
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.
Public relation defense (Score:4)
I have just finished reading Secrets and Lies [counterpane.com]. 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.
Comment removed (Score:4)
Re:how many more buffer overflows is it going to t (Score:2)
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.
Re:Proof-Positive (Score:2)
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.
Re:how many more buffer overflows is it going to t (Score:2)
If we're going to undermine buffer overflows completely, we may as well go back to using Cobol or Fortran. No buffers there.
It'll end up just like warez! (Score:2)
Re:Won't help the "general user", at least not a l (Score:2)
Re:how many more buffer overflows is it going to t (Score:2)
Depends on if there's an exploit yet (Score:2)
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.
Re:how many more buffer overflows is it going to t (Score:2)
I say let the compiler do the work, wherever possible. Isn't that the whole point of compilers?
I hate having to explain a joke (Score:2)
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 [watchfuleye.com] 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.
Re:Fights script kiddies (Score:4)
Re:Won't help the "general user", at least not a l (Score:2)
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.
Re:Covers just about everyone then! (Score:2)
Re:Um...No... (Score:2)
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.
Re:Wouldn't help (Score:2)
Re:Wow! Now is time to drop BIND??? (Score:3)
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
--
Re:other qualified parties (Score:2)
But then again I'm not ISC. I can't imagine something like this working, though, without a very tightly limited list of members.
Re:Buggy internet name daemon (Score:2)
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.... (Score:4)
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.
Re:If Vixie could write a decent piece of software (Score:2)
All the more reason to upgrade to Bind 9 instead of sticking with the Bind 8 codebase.
Re:Won't help the "general user", at least not a l (Score:2)
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.
-
Too much buggy code... (Score:3)
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.
Oh just brilliant. (Score:2)
This will set back co-operation in the security field by years.
--
Remove the rocks to send email
Totally against the ethos of Open Source... (Score:2)
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.
Re:members only is one thing, but fee-based?? (Score:2)
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.
-
Some flaws are found by crackers... (Score:2)
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.
Re:how many more buffer overflows is it going to t (Score:2)
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.
Re:That's absurd. (Score:2)
That's just silly. Critical infrastructure is by definition critical, and they need advance warning (if at all possible). If a vulnerability is already public and exploits are in the wild, then a group like this doesn't serve any practical use and should (and likely will) be circumvented in favor of more direct announcements and patch releases.
Re:how many more buffer overflows is it going to t (Score:2)
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.
Re:Easier for sysadmins, not harder for crackers! (Score:2)
Re:Full-disclosure != instant release of exploit. (Score:2)
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
Re:how many more buffer overflows is it going to t (Score:2)
There are plenty of examples of plausible C code which exhibit this behavior. (cf BIND)
Just using a safe language isn't enough, but it sure is a start!
There are TWO reasons why BIND gets exploited (Score:2)
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.
the advantage of security through obscurity (Score:3)
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.
of course (Score:4)
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?
Makes sense... (Score:3)
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
This actually isn't a bad idea (Score:5)
members only is one thing, but fee-based?? (Score:5)
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?
Too Many Secrets (Score:3)
--
My response.... (Score:5)
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
>
>
>
BIND security (Score:2)
Security through Obscurity, eh? (Score:3)
Alex Bischoff
---
Re:but not if you want any advanced features (Score:2)
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.
Re:how many more buffer overflows is it going to t (Score:2)
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.
Re:how many more buffer overflows is it going to t (Score:2)
Re:how many more buffer overflows is it going to t (Score:2)
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.
try longest uptime chart instead... (Score:2)
http://uptime.netcraft.com/up/today/top.avg.html [netcraft.com]
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
Re:Where's Your Courage? (Score:2)
This was about a month before the big BIND vulnerability became public. The timing wasn't ESP, it was pro-active security, but it sure made our group look good when the announcment hit 'mainstream' news sources.
Re:how many more buffer overflows is it going to t (Score:2)
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.
Re:It'll end up just like warez! (Score:2)
The 'CORE' mailing list was similar to what is proposed for BIND, and archives were actively traded between hackers in the late 1990's. I still have a copy somewhere.
Exploits for 'statd' were traded in the underground for years before the problem became public.
Hrm... Bind (Score:2)
Tits on a boar? (Score:2)
Re:There are TWO reasons why BIND gets exploited (Score:2)
If all the NDAs stipulated a finite time period of not more than 7 days, allowing anyone to release the information at that point, then I would believe you. 7 days is plenty for a vendor to get their act together. In fact 1 business day is enough, really. But I'll allow for 7 given that there are always stupid managers getting in the way of real work.
Instead, this is a means to allow Paul Vixie to cover things up while he doesn't make much effort to fix it. Someone who continues to release known bad programming methods isn't likely to be very adept at rapidly fixing exploits anyway. And this secretive approach only means the rest of us have to sit around like mushrooms while the cracker nets are passing the info around in their own secretive ways to avoid getting caught.
chroot'd bind (Score:2)
(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.)
Re:how many more buffer overflows is it going to t (Score:2)
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.
Re:We became BIND-free, and love it. (Score:2)
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.
Re:Use djbdns if you want security (Score:2)
djb's license in a nutshell: you can redistribute the tarballs AS IS freely. You can distribute pristine binary packages freely. You can use / modify freely, but you can only distribute modifications as patches.
I agree, it's a *major* pain in the ass, but would you rather have some bloated, compromised, resource hogging, buggy crap like Bind or sendmail on a 'mission critical' service like DNS or mail?
And then, while it's a pain in the ass, it's still *free* software. Annoying license, but still free (just like the Qt licence).
--
Re:how many more buffer overflows is it going to t (Score:2)
As an addendum, almost any code written for The StreamModule System [omnifarious.org] is immune to buffer overflows because of the way buffers are handled. It's really not hard. The tools are available.
Re:DJB's code may be secure, but it's a pain.... (Score:2)
Interesting. Perhaps it is easier to administer. But I hope it isn't as hard to do a startup as qmail was with daemontools. I hope it doesn't have as many processes running as qmail did. And I hope it uses no more than a single userid. As for configuration, it looks like it's command oriented while I prefer file oriented (e.g. my own scripts generate all the files from data stored elsewhere anyway). But this operates in a total replacement mode since they can't really determine incremental changes reliably. I should be giving it a try in the next couple of weeks.
Languages don't make buffer overflows .... (Score:3)
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.
Re:The problem is C, not C++ (Score:2)
Over the years I've collected a few string functions I've written. I'm starting to write some more, and I'll be releasing the library in the next few months. OK? Tell me what kinds of functions you'd like to see in C.
Re:This actually isn't a bad idea (Score:3)
Well, while I can see your point, Script Kiddies don't really care if bugtraq posts an exploit or not. They get their exploits from l33t d00dz, not bugtraq. Besides, when is the right time to post an exploit? Good sysadmins want one immediately to see if they're in danger. Bad ones never want one, because they don't know or care there are security holes in their software until a kiddie reminds them that bugtraq is not the only sploit source.
Fights script kiddies (Score:4)
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.
--
Re:I can kinda understand (Score:2)
Except for two small problems. One, every comprimised box becomes yet another weapon to use in a DDoS attack. Two, recovering from a comprimise is an incredible pain and takes a lot of time and effort.
This is regardless of whether or not you kept 'top secret' information on a box connected directly to the Internet or not.
Lastly, you are obviously a complete jerk and idiot since you can't seem to make any point at all without resorting to abusive language and calling people names.
Re:I can kinda understand (Score:5)
When the latest BIND 4/8 bugs hit, people were reporting attempts to exploit the bug almost immediately. That's really bad.
So, is it OK to do this in an attempt to give the good guys a jump on the bad guys? Maybe. I'm very leery of any circumstance where bugs are actively hidden. I do believe that disclosure is key in any security situation. That having been said, I don't think that a closed list which agrees to discuss bugs locally before full disclosure is all bad.
Oh yeah. This is a good idea... (Score:2)
... 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.
--
Re:Makes sense... (Score:2)
Our reputation is staked on the idea that many eyeballs makes all bugs shallow, and that we can, in most cases, fix things faster than the script kiddies can exploit it. Please note that the most notable DNS problem in our short memories was on MICROSOFT servers, not Mr. Vixie's precious code. Matter of fact, MSFT went to Akamai precisely because they were running Linux and BIND - something they knew wasn't easily hacked.
Open Source is not broken, Mr. Vixie. It doesn't need to be hidden under a pile of NDA's, much less "fixed." If you go thru with this hair-brained idea, I'll be one of a very large number of people to unceremonously consign your code to /dev/null.
I may do so anyway, just to make sure the old Cabal isn't pulling stunts on me behind my back.
No, I haven't forgotten you were once a junior member of that once august organization.
Rate me down if you want to, Moderators, I've got karma to burn. But IMNSHO, this effort against the very core of Open Source must be stopped, cold, and in such a way that no one ever thinks of doing it again.
(I wonder what would happen if someone forked the code at this juncture and GPL'ed it?)
--
There is TOO a Cabal.
Where the hell is spaf when you need him?
Wow! Now is time to drop BIND??? (Score:3)
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 [cr.yp.to].
Check out this: http://cr.yp.to/djbdns/namedroppers.html [cr.yp.to]. 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!
partial solution at best (Score:2)
Now, if you can address THAT, then that'd be progress.
Re:members only is one thing, but fee-based?? (Score:3)
Pure speculation, but it might just discourage people from joining on a whim.
'Keeping out the riff-raff' so to speak.
Maybe they think people can be more trusted with sensitive info if they've bought it, rather than had it given to them.
Then again it might just be because they want to make a buck.
--K
BIND is not your typical software (Score:2)
P.S. I know using the phrase "net terror" is lame.
Make fun of me if you must.
but not if you want any advanced features (Score:2)
Won't help the "general user", at least not a lot (Score:5)
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...
Does it matter? (Score:2)
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).
It makes some sense (Score:5)
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.
We became BIND-free, and love it. (Score:5)
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 [cr.py.to], 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.
Re:Authors Bad Attitude Makes Me Nervous (Score:3)
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.
--
Re:j00 R ! 31337! (Score:4)
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.
Re:I can kinda understand (Score:5)
BIND user: My box was exploited because of a buffer overflow bug that we didn't know existed.
BIND bug ppl: Ah yes, we knew about that but we didn't tell anyone in case script kids heard about it.
BIND user: Great. Now all our top secret info had been stolen and it could have been prevented. If you made the bug public then WE could have decided what was best, and possibly taken the machine(s) offline until there is a fix.
Think of it this way. If it was discovered that there was a really easy way of unlocking all existing house doors, would you want that information hiding temporarily in case criminals learned about it or would you want to know so you could at least have a chance to board up the doors if you thought it was neccesary. Making the expolit information available to all admins (regardless of whether the hax0rz also know) puts the admins in control which is the right thing to do.
Also, the problem with this stupid idea of limiting information spread is that it assumes the script kids are more on the ball than the admins. If that _is_ true, then _that_ is the problem that needs solving because in the end a poorly administered box will always be cracked however slowly or quickly you get the exploit info out.
how many more buffer overflows is it going to take (Score:3)
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?
Re:Your thoughts (Score:3)