ISC [BIND]COMPENDIUM -=- Charging for Security?

[Devon Null]

ISC: Charging for Security?

- ISC's [BIND] has become the de facto standard for running name servers,
from the heavily used root server all the way to single-user Unix
workstations.

This has resulted in a monoculture: outside of some Microsoft-based
networks, virtually all name servers run [BIND]. The security problems in
[BIND] are numerous, with root hacks and denial of service attacks being
found over the years. The ISC [BIND] security page lists twelve "official"
security holes in various versions of [BIND].

ISC is now considering charging for access to security-related information
regarding [BIND].

<http://securityportal.com/articles/chargingforsecurity20010201.html>
=============================================

ISC: Charging for Security?


By Kurt Seifried <seifried at securityportal.com> for SecurityPortal

February 01, 2001 - ISC's Bind has become the de facto standard for running
name servers, from the heavily used root server all the way to single-user
Unix workstations. This has resulted in a monoculture: outside of some
Microsoft-based networks, virtually all name servers run Bind.

The security problems in Bind are numerous, with root hacks and denial of
service attacks being found over the years. 

The ISC Bind security page lists twelve "official" security holes in
various versions of Bind. 
<http://www.isc.org/products/BIND/bind-security-19991108.html>

If you visit any hacker Web site, chances are you can find dozens of
prepackaged "exploits" that will allow you to break into various versions
of Bind running on different Unix platforms. Currently, of the SANS top ten
security problems, Bind is number one.

CERT Advisory CA-1999-14 Multiple Vulnerabilities in BIND
<http://www.cert.org/advisories/CA-99-14-bind.html>

ISC is now considering charging for access to security-related information
regarding Bind:


From: Paul A Vixie <Paul_Vixie at isc.org>

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:

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)

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

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

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 at isc.org>.

I solicited responses from ISC and several vendors via phone and email.

Paul Vixie (Internet Software Consortium ? makers of Bind) communicated
with me in several emails. The (1) and (2) show which email exchange each
part is from. 

Minor editing of spelling and punctuation has been done.


Kurt Seifried (1): I'm doing an article on this, and I've solicited some
vendor response, but would also like to get ISC's reasons, etc. for this
(as well to explain to readers a bit more what is going on).

Paul Vixie (1): It's a bit early to do an article on it. That's why I
called the notice I sent a "pre-announcement." But I'll tell you what
little can be told and you can decide if it's newsworthy.

Kurt Seifried (2): From this I take it as a matter of when it will happen,
as opposed to if it will happen?

Paul Vixie (2): Bind-members absolutely will happen.

Kurt Seifried (1): Why do you think there is a need for fee-based membership?

Paul Vixie (1): ISC has strong ties to vendors who run bind9, due to the
vendor-funded project to write bind9 from scratch. However, ISC's contacts
to vendors (or to the different parts of some of the same vendors) who run
bind4 and bind8 are at the personal, 1-on-1 engineering level. It's now
desirable to formalize and deepen the ties between ISC and those vendors or
parts of vendors who are responsible for shipping BIND, and patches to
BIND, as part of their products.

Kurt Seifried (2): So unless you sponsor ISC or pay the membership fee you
will be unable to get support from ISC in the form of software patches,
etc.? I.e., you will have to rely on "official" releases (such as 8.3.2 or
9.1.0) or fix it yourself?

Paul Vixie (2): Not at all. ISC has always published patches and will
continue to do so. However, the next time we learn, through CERT or
otherwise, that there is an attackable bug in code that we've published, we
hope to have a direct and very private communications forum with the people
who run the Internet infrastructure or who need lead time to prepare
patches for THEIR customers.

An important point to make, if you're going to write about this, is that
nothing ISC has historically done will stop. The code is still completely
redistributable under the Berkeley-style license (which, unlike the GPL,
allows vendors to distribute binaries based on modified sources without
sharing those source modifications with ISC or anybody else). CERT will
still be ISC's channel for announcing security bugs to the community.
Patches will still be accepted from the community, and published to the
community.

The ONLY thing bind-members will do is ADD SOMETHING NEW. Nothing old is
being taken away. All that was, remains. What we're adding is a way for ISC
and the vendors who ship BIND in their products to speak privately and
securely without awkwardly depending on CERT as the communications channel.
(But note that CERT will still receive early notice of any attackable bugs
just as they always have, there is no intent to cut them out of the loop.)

Kurt Seifried (1): What recent events have shown this?

Paul Vixie (1): While preparing for this week's CERT advisory, ISC found
that speaking to vendors through the CERT advisory process was somewhat
awkward and made for extra work on both sides.

Kurt Seifried (1): The NDA, I assume this is to prevent people from jumping
the gun on announcements and distributing code from CVS?

Paul Vixie (1): Absolutely. Only ISC or its contractors can distribute new
versions of BIND.

Kurt Seifried (2): By this I assume you mean an "official" Bind
x.x.x.tar.gz, as opposed to "Generic Linux" shipping Bind-x.x.x.tar.gz
compiled and packaged up, correct?

Paul Vixie (2): Right.

Kurt Seifried (1): Do you have any idea or ballpark figures on what
membership will cost, for example say a vendor like IBM, and/or Red Hat
Linux? I.e. $500, $5,000, $50,000 per year?

Paul Vixie (1): I can't comment on that at this time. However, you can use
the gradiated pricing model of the old X Consortium as a "similar-sounding
model" to get the point across to your readers that (a) this has been done
before, and (b) details will be announced when ISC is ready to announce them.

Commentary

Vincent Danen (MandrakeSoft ? makers of Linux Mandrake):

I think the decision of the ISC to make a bind-members group that is not
public for the future development and early disclosure of security problems
related to the BIND software is an extremely bad idea. While I understand
the need to protect the code from malicious users, I fail to understand the
need to charge for the privilege of being amonst this "elite" crowd, and I
absolutely disagree with members being forced to sign a non-disclosure
agreement. If the ISC indeed goes ahead with this, I hope the Open Source
community, to whom this is a severe slight, decides to move forward with
either a branch of the BIND code to audit, secure, and most importantly
keep it 100% free, or a similar BIND replacement package. This is, of
course, my own personal opinion, and not necessarily the opinion of my
employer.

Greg Kroah-Hartman (WireX Communications ? makers of ImmunixOS):

"We don't like this at all. If you are on the linux-elitists mailing list,
there's a great description of why someone thinks ISC is doing this (I can
forward it to you if you can't find it). And I don't think that we would
pony up the money to play with this."

<http://zgp.org/pipermail/linux-elitists/2001-February/001494.html>

    |========================================|
LISTING of [linux-elitists] mailing list Archives:
SORTED by [Month][Thread][Subject][Author][Date][Gzip'd Text]
<http://zgp.org/pipermail/linux-elitists/>

Subscribing to linux-elitists

Subscribe to linux-elitists by filling out the following form. 
<http://zgp.org/mailman/listinfo/linux-elitists>

"[linux-elitists] -- Because everyone else really is dumb."

This is a closed list, which means your subscription will be held for
approval. You will be notified of the administrator's decision by e-mail.
This is also a private list, which means that the members list is not
available to non-members.
    |========================================|

Dragos Ruiu (Dursec ? IDS expert and author):

It is unfortunate that right now, no credible alternative exists to bind,
whose development by the ISC and Mr. Vixie's desire to close the sources
for it, locking out all except the for-pay cabal members from viewing
critical security information about it, leaves the entire Internet reliant
on a dubiously managed monocultural single point of failure with a poor
past record of security.  The only current credible alternative to bind
I've found is currently djb-dns, whose restrictive license prohibits anyone
except DJB from distributing patches or any code modifications or
derivatives, and this situation, if no other alternatives arise, leaves the
Internet at a high risk of a massive systemic failure - an unpleasant
prospect.

Theo de Raadt (Head of the OpenBSD project):

ISC has been building a "one shoe fits all" DNS server, designed for
everything from small servers to root servers with the .com hierarchy on
them. Good security software has well constrained behaviours and small
subcomponents, so that unexpected results are minimized. BIND is not
written that way, and has hundreds of little features. It can be very
difficult to assure the quality of software designed to run in a wide
assortment of ways. None of the BIND implimentations has any of the basic
principles we see in great security software, and when we add in the
uniquitous and mono-cultured nature of it's deployment, the discovery of a
really nasty bug could hit really hard. Say, I LOVE-YOU.in-addr.arpa?

We need more DNS server choices.

A long list of emails was posted to Bugtraq. Of 23 emails posted, only one
was supportive, and this was the personal opinion of an employee from a
major ISP (rr.com). Among the comments were:


From: "Larry W. Cashdollar" <lwc at Vapid.dhs.org>

This means only system crackers and paying parties will be aware of
security issues.  How is this model going to benifit the internet as a
whole and the security community?  I rely on free information from lists
like bugtraq and cert to keep my systems secure.  I now have to pay for my
own security?


From: Security Admin <security at cyberlink.ch>

VERY harmful. This is screaming for a code-fork, for the same procedure
that happened with SSH. If ISC doesn't back off, we're soon gonna have
OpenBind.


Bind is not some simple application we can live without; it is one of the
fundamental components of the modern Internet. This type of fee-based
member forum sets an extremely worrying precedent. ISC also controls DHCP
(Dynamic Host Configuration Protocol), which is used by many large
organizations to remotely configure workstations for network access.

If ISC is successful in this venture, similar software vendors will be
tempted to do the same, as it offers a nice revenue stream for a service
they currently provide for free. Furthermore, the restriction of access to
information will only result in non-member vendors taking much longer to
ship updates, hurting their customers and increasing the number of
vulnerable Bind servers.

ISC is playing with fire. They run the risk of seriously alienating the
user community and operating system vendors, who, if backed into a corner,
may not sign the NDA and pay the membership fees.

SecurityPortal.com <http://securityportal.com>
(C) Copyright 1999-2001 SecurityPortal, Inc. All rights reserved.
    |========================================|


Internet Software Consortium: BIND Vulnerabilities
<http://www.isc.org/products/BIND/bind-security-19991108.html>

    |===============<-30->===============|