[18960] in bugtraq
Re: Security information for dollars?
daemon@ATHENA.MIT.EDU (Robert Watson)
Fri Feb 2 13:46:06 2001
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID: <Pine.NEB.3.96L.1010202083650.21851A-100000@fledge.watson.org>
Date: Fri, 2 Feb 2001 09:13:32 -0500
Reply-To: Robert Watson <rwatson@FREEBSD.ORG>
From: Robert Watson <rwatson@FREEBSD.ORG>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <20010202080607.J52423@gsmx07.alcatel.com.au>
While I'm not strictly opposed to the idea of a vendors-only notification
list for BIND bugs from ISC, there are a number of things that have to be
kept in mind:
1) People can and do follow commit mailing lists. ISC/Nominum's commit
mailing list may be private, but the commit lists for the *BSD projects
are all public. It has been demonstrated on a number of occasions that
people do actually read the commit lists, read the diffs, and that
they aren't stupid. When security fixes are committed to the FreeBSD
source tree and our advisory is delayed for whatever reason, e-mails
start popping up on the FreeBSD security-officer mailing list saying,
``Are you going to release an advisory for this?'' ``This is a serious
problem and if you don't release an advisory, we will'' ``Is this
being covered up?''. We do try to coordinate the patching of bugs
in our tree with the release of advisories, but a fundamental problem
here has to do with the QA of the fix: CVS is how we serialize changes
to the tree, as well as distribute the changes among developers. If we
want wider testing in the developer community, it needs to be through
CVS so that we have a "final" integration of the patch against a fixed
version of the source tree. And as soon as it's committed, the world
knows. Part of the goal of an open source and open development
project is transparency -- most of the time, this is a benefit.
2) Getting fixes from the Vendor in advance of the release is very
difficult. We delayed the release of our advisory because the
"official" fix for the bug was BIND 8.2.3-RELEASE. It takes us several
days to properly integrate a new vendor release into our tree on
three code branches (5.0-CURRENT, 4.2-STABLE, 3.5-STABLE), develop
and test updates against release versions, and do proper QA and
testing. Releasing a broken fix helps no one: testing must occur
first. Unlike what was claimed in an earlier e-mail, we had almost
a month's advance notice of the vulnerability through CERT. We just
didn't have the fix; we were asked to avoid disclosing the bug early,
and it was clear to us that committing an advance fix prior to
integrating 8.2.3-RELEASE would be about as plain to the concerned
community as an advisory. We hoped that ISC/Nominum would release
BIND 8.2.3-RELEASE in advance of notifying of the security problems
in it, so that we would have time to integrate and test before
the advisory. Instead 8.2.3-RELEASE went out the door on Jan 26,
on a Friday late at night, and advisories begain popping up on
Monday. Of course, the reality is that people diff releases to
find security holes, as described in (1), so perhaps early access
to the release doesn't work either. Trying to avoid releasing on
a Friday would be a good thing, and has been discussed a number of
times on bugtraq before.
3) The bind-members group sounds like it is really targetted at
closed source systems: the reality of open source development is that
it's done by large teams of people, that work is done by the first
person who gets to it, resources for travel are relatively scarce, and
that the people cooperating on open source software often don't have
any binding contractual relationship. Requiring the signing of NDA's
and the idea that in-person meetings be an important components of the
organization will substantially hamper the participation of open
source groups in the process. We discussed this to some extent
internally in the FreeBSD Project, and came up with a list of no less
than 8 people who would need to participate, based on the distributed
nature of the security-officer list, maintainers of the BIND code
in our tree, etc. And there isn't an "umbrella" organizationt that
can sign the NDA and then delegate tasks internally. Also, the NDA
may be quite incompatible with the nature of commit mailing lists,
discussed above, which play a vital role in open source projects that
use them.
4) As has been brought up, the NDA may present problems from other
perspectives also: if it is known that a security vulnerability is
being widely exploited, the "strong NDA" needs to take into account
the desire for early release rather than delayed and coordinated
release. If there is an NDA, it must come with a commitment that
release of information and fixes can be done in a timely manner, not
after a 30 day delay, during which time hundreds of thousands of
machines are vulnerable. Having the root server operators in on
the list is an interesting twist however, that may help: must
vendor vulnerability mailing lists don't contain independent users
of the products.
Vendors want, and need, advance notification of bugs so they can best
serve the users of their system. Doing this advance notification in a
structured manner is also necessary, to allow all interested vendors to
get notification, and to organize the advisory process to minimize risk to
the users of various systems. A failure to organize the advisory process
does a disservice to users of open source and closed source software, but
it's necessary to keep in mind the development models used in open source
software, and how they are not necessarily compatible with delayed
advisories, NDA's for developers, and timed release.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
robert@fledge.watson.org NAI Labs, Safeport Network Services
