bugtraq - RE: Microsoft and Security

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]

Message-ID: <20040705191943.GB59306@mail01g.rapidsite.net>
Date: Mon, 5 Jul 2004 16:10:36 -0700
From: "Alun Jones" <alun@...is.com>
To: "'Justin Wheeler'" <jwheeler@...ademons.com>,
	<bugtraq@...urityfocus.com>
Subject: RE: Microsoft and Security

Justin Wheeler <mailto:jwheeler@...ademons.com> wrote on Monday, July
05, 2004 10:58 AM: 
> The simple argument I was making was that if MS' "testing
> process" is what
> keeps patches from coming out in a timely manner, perhaps they should
> actually be of decent quality.  When you're getting patches
> that are both
> slow to release, as well as adversely affecting the systems
> they're being
> installed on, MS has met neither of their agends.

It's not "either perfect quality assurance or immediate patching", sadly.

We spend so much time in our binary world, that we forget that real and
complex human processes are not binary - there are a large number of shades
of grey.

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.

It's a balancing act, and one performed without a net.  And we've only
touched on two of the variables in this balance.  There's also third-party
software, whose vendors tend to get a little tetchy when their software
doesn't work the same way it has for years, even if it's because they're
relying on undocumented and unsecure behaviour.  There's probably a dozen
other variables that you need to consider.  If you've ever had to respond to
a security vulnerability (perhaps if you've had to respond to more than
one), you'll understand the way that the process works, and that a rushed
untested 'patch' is worse than the worst tested patch.

A tested patch will at least work on the majority of systems.  An untested
patch runs a high risk of not working at all.  The problems you've pointed
to are issues with outliers - usually customers running specialised software
- not widespread damage to people with mundane configurations.  Usually such
outlier customers would be the ones most able to test their own
configurations prior to rolling out any patch, though, and I would always
suggest that those who can test, should test, any patch or upgrade in their
own environment prior to patching.

Microsoft employs people who care about producing good software.  We're all
indoctrinated from day one that our software is used by everyone - our
parents, our neighbours, our children...  It's perhaps a unique situation
compared to producers of the other OSs, where the users are usually limited
to particular sections of the community.

I really don't think you'll find much truck with the idea that Microsoft
employees are happy to leave their mother's home machine, or those of the
general public, open to infection.

Alun.
~~~~