Subject: zlib & Microsoft: RISK of adopting FS code w/o FS practices?
From: "Karsten M. Self" <>
Date: Fri, 15 Mar 2002 11:51:23 -0800
Fri, 15 Mar 2002 11:51:23 -0800
The zlib security issues of the past week have raised some interesting
issues.  Initially the read was that this was bad news for GNU/Linux and
free 'Nix, which made extensive use of the affected libraries in
utilities and the OS kernel itself.

Then news broke that Microsoft is also vulnerable based on its
appropriation of the zlib libraries (licensing of zlib is along the
BSD/MIT style, allowing for this).  So zlib code may be scattered in
many places throughout Microsoft products, applications, and possibly
the OS itself as well.

This struck a cord when I watched an WinNTW 4.0 SP 6 system booting at
work, and I caught a familiar message:  "Build 1381".  If I'm reading
this right, it's the fundamental OS build that's being used by the
system.  And 1381 is the same kernel I had (briefly) on my desktop in

Proprietary code has a strong tendency to rev very slowly, and a given
build of a program may be extant in large numbers for years.  Part of the
security of free software comes in the quick cycle time -- people outrun
the bugs.   The other side of the security coin comes from the rich
multitude of software versions out there.  While it's (sometimes) a
nightmare for compatibility, it also makes the cracker's job more
difficult -- scripted attacks are likely to work against only a small
number of vulnerable systems, just by virtue of the changing target
syndrome.  In the meantime, not only are a large number of static
proprietary systems impacted by the zlib bug, but likely neither
customers nor vendors know just where the affected code is.

The risk here is rather similar to the one pointed out (with a certain
charming amount of repetition) a couple of years ago by a Louis A.
Mettler (largely a crank, but a prolific one).  His beef was that free
software was inherently less secure than proprietary code, because as he
put it "the secretary's got the source code".   The zlib issue points
out that this source exposure is no less true of proprietary software,
and that the real risk isn't with making source available, but with
restricting access and awareness to it.

I'll wager that a significant portion of Debian systems are already
revved past this week's zlib flaw, and that most other GNU/Linux distro
installations will be moved past it within a matter of months (let's
face it, GNU/Linux users are upgrade junkies).  I'll also wager that in
three years, a significant portion of proprietary software systems based
on zlib code will continue to exhibit the exploit, while the GNU/Linux
and other free software systems have moved far beyond it.   

Food for thought: you can't half adopt FS.


Karsten M. Self <>
 What part of "Gestalt" don't you understand?       There is no K5 cabal

["application/pgp-signature" not shown]