Re: MS02-064 fix time

["Steven M. Christey" <coley () linus mitre org>]

David Litchfield said:

> I warned MS of this back in on September 6th 1999 whilst 2k was still
> in BETA (See the bottom of the following mail)
> http://security-archive.merton.ox.ac.uk/bugtraq-199909/0145.html
>
> I wonder if this is the longest time it has taken for a "fix" to be
> made public after disclosure?

Since approximately 45% of *all* CVE identifiers (CAN- or CVE-) have
not been clearly acknowledged by the vendor [1] - and therefore do not
have a proven fix - this probably isn't the longest time.  (By the
way, the lack of vendor acknowledgement is one of the biggest factors
in preventing candidates from becoming accepted as official entries.)

Based on a quick grab of some (incomplete) disclosure data I've been
gathering, the following took longer:

  March 28, 2002: SGI addresses the "FTP Bounce vulnerability"
  (CVE-1999-0017) in advisory 20020305-01-I.  The problem was first
  published sometime in July 1995, and a CERT advisory was released in
  1997.

  Note: FTP bounce is a significant design problem from the original
  RFC; as I understand it, "fixing" it can violate the RFC.

There may be other cases, but the data is currently incomplete and
only covers the first half of 2002.

In general, design problems are much more difficult to fix.
Hopefully, design choices can be subjected to as much third-party
review as possible *before* a product is shipped.  This seems
difficult to accomplish if the design itself is kept secret.

Delays of more than a year occur relatively often, maybe once a month.
3-month delays between notification and release are commonplace,
probably several times a week.

In genral, however, there are *very* few statistics regarding when
vendors were first made aware of bugs.  Vendors don't publish this
information themselves, and very few researchers give precise dates.
(Vendor statements in the CERT/CC Vulnerability Notes are a good
resource, but they are incomplete.)  I estimate that only about 10% of
this year's vulnerabilities have quantifiable notification-to-release
time frames, and this is probably the best year for such stats, as
more researchers are starting to report such information.  But some
researchers only say that they notified the vendor "a while ago,"
which doesn't allow consumers to determine exactly how much time
passed before the bug was publicly announced.

Vendors or developers who want to compete on speed-of-fix would do
well to advertise these specifics.  It gives them a standard to live
up to, and it would raise the bar for other vendors.  For example, in
the just-announced BIND vulnerabilities, various Linux vendors have
provided a fix within 1 business day of receiving initial notification
[2] [3].  This speed is a laudable accomplishment but, unfortunately,
a far-too-rare occurrence overall.

Consumers are encouraged to ask their vendors how long it has taken to
fix the last N reported vulnerabilities in their products.  They are
also encouraged to ask their vendors if they regularly monitor mailing
lists such as Bugtraq.  They may be surprised by the answer.

Vulnerability researchers are encouraged to publish their own
disclosure timelines (especially specific notification dates), which
will help all consumers - and the security community - understand how
responsive vendors really are.

- Steve


[1] An early study of vendor acknowledgement is at
    http://cve.mitre.org/board/archives/2000-09/msg00038.html, but the
    statistics remain stable.  Today's 45% figure is based on 4853 CVE
    identifiers, most of which involve issues that were first
    published in January 2000 and later.

[2] SuSE advisory SuSE-SA:2002:044
    http://www.suse.de/de/security/2002_004_bind8.html

[3] Debian advisory DSA 196
    http://www.debian.org/security/2002/dsa-196