North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Reasons why BIND isn't being upgraded
- From: Greg A. Woods
- Date: Sun Feb 04 03:18:45 2001
[ On Saturday, February 3, 2001 at 22:55:35 (-0500), Adam Rothschild wrote: ]
> Subject: Re: Reasons why BIND isn't being upgraded
> On Sat, Feb 03, 2001 at 06:34:36PM -0500, email@example.com wrote:
> > It seems obvious, the goal is to get the root-servers upgraded and
> > OS vendors notified so they can release patches/updates before holes
> > become public knowledge.
> > As someone else mentioned, some OS vendors have histories of taking
> > an unreasonably long time to release updates for known
> > vulnerabilities.
> Yup. And by the time OS vendors are notified, easily executable
> exploit code is already in the hands of the script kiddies. While it
> might not be "public knowledge" yet, those who need to know in order
> to initiate their attacks, probably do.
Exactly right. In the real world EVEN if the very first, cronologically
speaking, discoverer of a vulernability is a nice good clean-cut
law-abiding "Good-ole-boy" who immediately reports it to ISC and only
ISC, there's almost certain to be a kind of gestalt that results in many
not so well mannered and/or law abiding types discovering the same
vulnerabilities in very short order, and with exploits soon to follow.
Remember that even on BUGTRAQ it's rare to see exploits posted before
strange events begin happening, or usually before a fix for some bug is
checked in to one of the various open-source repositories where the
software in question is maintained. I also get the distinct feeling
that the exploits we do see on BUGTRAQ are often examples that come from
the "Grey Hatted" majority, and that it's very rare to get open
disclosure of exploits from anyone wearing a truly jet-black hat (even
anonymously or third-hand :-). [Clearly some exploits are even crippled
by the poster.]
And that's not even to mention all the other problems that have been
pointed out by others showing that NDAs and open source development just
cannot possibly ever mix with any valid degree of success....
Indeed it's not that ISC is changing anything from their recent ways of
doing things -- this is just the straw that breaks the camel's back.
They've already long ago withdrawn the BIND development far enough from
the really ideal model of open source development (as exemplified by the
likes of the *BSD's, most multi-developer projects on SourceForge, most
of the non-commercial GNU/Linux projects, etc.) and they already have
commercial support service offerings that have at least the potential of
providing customers with secret fixes to already known problems. All
they're apparently doing is trying to more agressively market this
service. Whether their motives are altruistic or economic is irrelevant.
After all, how many people who really want to run open-source operating
systems are in fact actually running Solaris that they've built from
source? My guess is none. I haven't even bothered to get a copy even
though at one time I would have thought it to be the cat's meow.
In the end it's not really going to matter what software the root and
and whatever TLD servers buy in if ISC takes to supporting them under
NDA -- they'll just be "black boxes" holding the Internet infrastructure
together and they'll be held accountable as such. The people who want
true open-source nameserver software for their own zones will either
keep their ears to the ground and openly fix bugs in a timely fashion in
a forked version of the BIND code, or they'll turn to an independent
implementation, just like has happened with SSH and various routing
daemons. In fact, what do you know, but it's already happening!
The imposition of an NDA on ISC's proposed bind-members group is the
problem. It does not serve the open source community and it cannot by
definition. It stands just as much of a chance of backfiring as it does
of protecting ISC's potential for revenue by protecting the paying
vendors' ability to hold the attention (and pocketbooks) of their
customers. It will cause people to seek alternatives.
Greg A. Woods
+1 416 218-0098 VE3TCP <firstname.lastname@example.org> <robohack!woods>
Planix, Inc. <email@example.com>; Secrets of the Weird <firstname.lastname@example.org>