[Full-disclosure] what we REALLY learned from WMF
fw at deneb.enyo.de
Fri Jan 6 12:08:01 GMT 2006
* Gadi Evron:
> What we really learn from this all WMF "thingie", is that when Microsoft
> wants to, it can.
> Microsoft released the WMF patch ahead of schedule
> ( http://blogs.securiteam.com/index.php/archives/181 )
> Yep, THEY released the PATCH ahead of schedule.
They already did that for the IIS WebDAV issue, just before the
U.S. attack on Iraq.
> Why should they be releasing BETA patches?
They claim they do. It's called "Patch Validation Program", and
access is kind of restricted because it also covers issues which are
not yet public, and Microsoft doesn't want you to throw the patches at
some advanced diffing tools.
If conference presentations by Microsoft employees can be trusted, the
real issues with Microsoft patches (not the WMF patch, it's atypical
in this regard) is that they always forward-port the whole component
to the respective HEAD version. From a software engineering
perspective, this looks like a good idea because it helps to contain
divergence. But it also means that very extensive testing of patches
is required because a very simple two-line fix to address a very
localized buffer overflow turns into a massive upgrade operation. It
only pays off if you've got to fix several non-localized defects in
sequence, which doesn't seem to happen that often. In all other
cases, patches are much more likely to come with unwanted side
effects, which makes their deployment so much harder.
This leads to yet another factor: If you a corporate IT guy
responsible for patching, and there's a beta patch out there, you'd
often be forced to install it, no matter what. Most IT departments
aren't strong enough on their own to put forth a patching schedule and
adhere to it, and most people in the field very much like the
regularity of Microsoft's security updates. They don't care much
about all this window-of-exposure stuff, perhaps rightly so.
Full-Disclosure is hosted and sponsored by Secunia.