Reasons why BIND isn't being upgraded

I'm a bit confused. ...

Yes.

Will the ISC implement similar policies with its INN and DHCP software
in the foreseeable future, or is this something unique to BIND?

I don't see INN or DHCP as critical to the internet's infrastructure, so, no.

CERT has NEVER been the source of early warnings. By the time they release
information it has already been dissimenated in a variety of other forums.

Nevertheless CERT is the mechanism ISC has always used to get critical bug
notifications out to the industry, and there are no plans to change that. If
you think CERT's methods are unsuitable, please take it up with them directly.

So, the more critical to the Internet's infrastructure software is,
the more difficult it should be for non-"privledged" people to be made
aware of key security announcements/patches in a timely manner?

Why not just notify everyone at once? That way, when vulnerabilities
are discovered, people can take whatever action they deem appropriate
to protect their infrastructure (write/release their own set of BIND
patches? upgrade to djbdns? decide DNS is too daunting to manage
in-house, and outsource to Nominum or UltraDNS instead?), rather than
remain vulnerable, pending an official announcement from the
appropriate sources.

-adam

You mentioned in your pre-announcement TLD operators being eligible for
this new list, but made no mention of domain name registrars.

I count 141 ICANN "fully: accrediated domain name registrars, with an
unknown number of secondary registrars due to systems like OpenSRS.

These organizations collectively handle second-level name resolution for
the overwhelming majority of the millions of .com, .net, and .org domains
in use on the Internet. And while I haven't done a survey, I'd surmise
that they overwhelmingly use BIND.

Will these 141 organizations many of whose business relies on BIND be
eligible for your fee-based list? Do they consitute providers of "critical
infrastructure" in your eyes?

They're registrars. The don't directly provide DNS in any more critical
a nature than any commercial DNS provider.

And, since they're commercial organizations using BIND in a commercial
aspect, I think they can cough up the money.

> Will these 141 organizations many of whose business relies on BIND be
> eligible for your fee-based list? Do they consitute providers of "critical
> infrastructure" in your eyes?
>

They're registrars. The don't directly provide DNS in any more critical
a nature than any commercial DNS provider.

Precisely the point.

And, since they're commercial organizations using BIND in a commercial
aspect, I think they can cough up the money.

I wasn't questioning whether or not they should help to fund the
development of a product they are using to make money with(the majority
of them at least), I was asking if they are eligible to join the
restricted, fee-based list as providers of "critical infrastructure." If
one of them is hacked, it could potentially affect resolution for millions
of domains(depending on the size of the registrar.) I'd say that for
any company and it's customers, that's pretty critical, isn't it?

Disclaimer: I'm not a registrar myself, but I thought that GTLD registrars
sent everything to the NSI registry, and NSI still maintained the actual
zone files on the GTLD servers.

If this is correct, I would argue that they don't provide DNS in any way
(except to their internal machines); certainly, they're not part of critical
infrastructure (whereas *.gtld-servers.net, the contents of which they
contribute to, certainly are).

Therefore, they'd have less need to know about BIND security bugs than a
commercial DNS provider, or a non-profit DNS provider like us.

Vivien

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.

If the main goal is simply to help the net continue to function, it might
make sense to have a multi-tiered bind-members set of groups. BIND
developers would be the first to know about things, since they maintain
the code. Root-servers would be first to get security
notifications/updates. Then OS vendors would be notified (since this is
the level I expect most likely to cause information leaks). Perhaps then,
after a predetermined period of time, the notification goes public,
whether all the vendors have released updates or not.

It seems we already have the beginnings of this system. The [currently
known] holes in <8.2.3 were found and fixed. The root-servers all got
upgraded. Then we got a message posted around midnight EST friday night
on nanog (not bugtraq) with alot less detail than the average bugtraq post
basically saying, "there's holes...you better upgrade". At that point,
it's off to the races. You can bet people downloaded source for 8.2.3 and
compared its code to previous versions looking for the holes. Did you
upgrade before the first cracker found a hole and wrote an exploit?

I think ISC is trying to avoid this scenario in the future, but it's
unavoidable. Suppose things had gone differently. Instead of Vixie's
post friday night, sometime the following week we see a post from someone
(I guess it wouldn't be ISC if they plan to let CERT handle security
announcements...but CERT generally doesn't move very fast...so it wouldn't
be from them:) on bugtraq notifying us that new holes have been found, and
listing the various vendors who have updates ready and their update
instructions. At that point, we're pretty much back in the same situation
as friday night / saturday morning except that the upgrade process is a
little easier, much easier for the compiler challenged (or those
unfortunate people running OS's where development tools cost extra).

I think this is slightly preferable to what happened this time, as long as
the time periods are kept short. The longer it takes for a security
notification to go public, the more time we have for the information to
leak to the cracker community where you can bet an exploit will be
written and circulated.

If you read this far, thanks. I didn't intend to ramble on so long.

> And, since they're commercial organizations using BIND in a commercial
> aspect, I think they can cough up the money.

That's precisely the point. Even if they wanted to, ISC is saying they
can't. They're choosing who they think are important, or "critical".

I'm curious as to why ISC considers Sun, HP, etc more important to get the
information to Worldcom, Cable & Wireless, etc.

Is it because Sun, etc pay ISC licensing fees to distribute the software?

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.

You can bet people downloaded source for 8.2.3 and compared its code
to previous versions looking for the holes. Did you upgrade before
the first cracker found a hole and wrote an exploit?

No need; I'm running djbdns at work and home, and I'm unaware of any
major security problems associated with it. :wink:

[ obvious and/or rude content omitted. ]

> [...] How many people actually use the default vendor binaries
> anyways?
Just about every very large company that I've ever worked
with. Also, having spent numerous years working the NAVSEA and other
Pentagon systems, you are explicitly not permitted to install
anything other than a vendor-provided patch.

True. And many of these organizations are fully content running
exploitable versions of Sendmail 8.6, BIND 4.x, ftpd, telnetd, NFS,
NIS/YP, etc, if that's what their vendor's releasing. Their main
concern is not security, but rather, vendor accountability and
conformance with what they believe to be the status quo.

Others maintain higher standards.

My god, are there really this many idiots out there that don't grasp
how the world works?

Apparently.

-adam

[ On Saturday, February 3, 2001 at 22:55:35 (-0500), Adam Rothschild wrote: ]

Subject: Re: Reasons why BIND isn't being upgraded

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

How many of you use BIND in a commercial environment?
How many of you actually contribute money back to the authors of BIND?

Its all fine and good saying "When there's a security problem in BIND,
I want to know and I want to know now!" but guys, if you want this wonderful
level of support, either cough up some money to your software providers,
or write it yourself. I might not agree with how Paul is going about it,
but I understand his problems.

2c,

Adrian

Umm.. to be honest, I was upgraded about 2 hours after Paul's *Sunday*
note (the one that made clear that the security holes affected 8.2.2-P7).
I interpreted his Friday night note as "Here's 8.2.3, if you're on 8.2.2
there's security patches" with "security patches" meaning "the stuff
we've fixed in -P7 but you've missed if you don't do the -P? releases".

I'm positive I'm not the only person who missed the "-P7 is vulnerable"
implication in the Friday night note - although I'm also sure that
Paul was being intentionally obscure there...

        Valdis Kletnieks
        Operating Systems Analyst
        Virginia Tech