Date: Wed, 11 Feb 2004 11:41:56 -0500 (EST) From: Robert Watson <rwatson@freebsd.org> To: Mike Tancsa <mike@sentex.net> Cc: freebsd-security@freebsd.org Subject: Re: Longest known unpatched FreeBSD security issue ? Message-ID: <Pine.NEB.3.96L.1040211113608.75521B-100000@fledge.watson.org> In-Reply-To: <6.0.3.0.0.20040210154335.04a3c9f8@209.112.4.2>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 10 Feb 2004, Mike Tancsa wrote: > Does anyone know off hand what the longest known serious security issue > (i.e. remote compromise) has been with FreeBSD that went unpatched ? > e.g. security hole is reported to security-officer@FreeBSD.org. X days > later, fix and advisory committed. What has been the largest X ? > > My jaw dropped when I saw > http://www.eeye.com/html/Research/Upcoming/index.html I don't have any statistics on-hand, but advisories typically work in one of two ways: (1) The problem is brough tto the attention of the security-officer or security-team in a manner that iehter prohibits, or does not require, coordination with other vendors. You'll often see a week or two for fixes to be developed, and then maybe a week or so while advisories are generated, updates built, branches tested, etc. If it happens during a release cycle, you might see an additional delay of a week so that tags down down at the right time, etc. Delays are almost always coordinated with the reporter of the vulnerabilty, although I think we've improved substantially due to increasing staffing on security-team. However, some reporters want only minimal advance knowledge of the vulnerability, and so will require it to be directly handled by security-officer. (2) The problem is brought to our attention in a manner which requires coordination with other vendors providing the software or component -- this can introduce additional delays in the advisory cycle. In the past, we've seen coordination delays of up to (or maybe exceeding) a month. For example, CERT will aften schedule advisory releases three weeks or more past initial notification. I seem to recall one IP stack issue across many vendors that actually tooks several months to resolve. Delays also depend on the nature of the vulnerability -- sometimes a vulnerability is reported along with a fix, and sometimes it's simply a problem that needs to be fixed. Sometimes the fixes for vulnerabilities are clear (change buffer handling), but sometimes they are complex denial of service issues that affect interoperability with other systems (i.e., NFS/RPC/TCP problems). Obviously, nobody wants delays, but between available resources to fix problems (sometimes imposed by outside parties), coordination with vendors and reporters, and the inveitably complex nature of security vulnerabilities, things sometimes do take a lot longer than we'd like :-(. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040211113608.75521B-100000>