lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 7 Jul 2004 08:57:19 -0400
From: Adam Shostack <adam@...eport.org>
To: "David F. Skoll" <dfs@...ringpenguin.com>
Cc: Alun Jones <alun@...is.com>,
	'Justin Wheeler' <jwheeler@...ademons.com>, bugtraq@...urityfocus.com
Subject: Re: Microsoft and Security


On Tue, Jul 06, 2004 at 03:04:01PM -0400, David F. Skoll wrote:
| On Mon, 5 Jul 2004, Alun Jones wrote:
| 
| > The immediate patch carries maximum risk, and the perfect patch requires
| > unconscionable amounts of time to verify its correctness.  Between those two
| > endpoints, however, you'll find a huge variance in what is acceptable risk
| > of damage from a patch versus acceptable delay to test.  And unfortunately,
| > neither of those two values is a) measurable, or b) the same for each user.
| 
| That's true.  However, Microsoft has a much higher record of patches that
| break things than most other vendors.  I don't believe that's because
| the people who write the patches are less competent, but I do believe it's
| because they are patching a horribly-designed system.

That's a common perception, but when we looked at vendor patch
updates, as an indicator of patches that have problems, we didn't see
it.  And really, we looked.  We would have been happy to tweak vendors
for releasing shoddy patches, because bad patches stand out in an
admin's memory, while ok patches cognitively disappear.

Now, it could well be that the problems that cause MS to pull a patch
and replace it are more severe than the ones that cause a Linux vendor
to do so.  We didn't examine that, although I'd love to see someone do
that study.  What we found was that about 1 patch in 6 gets replaced
at some point, and most of that happens in about 30 days or less.

Adam

Timing the Application of Security Patches for Optimal Uptime 
Steve Beattie, Seth Arnold, Crispin Cowan, Perry Wagle, Chris
Wright, and Adam Shostack.  Presented at the USENIX 16th Systems
Administration Conference (LISA 2002), Philadelphia, PA, December 2002
http://www.homeport.org/~adam/time-to-patch-usenix-lisa02.pdf


Powered by blists - more mailing lists