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
