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