full-disclosure - Re: Microsoft product vs Microsoft patch

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: Thu, 24 Aug 2006 17:05:43 -0400
From: Valdis.Kletnieks@...edu
To: n3td3v <xploitable@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Microsoft product vs Microsoft patch

On Thu, 24 Aug 2006 20:14:03 BST, n3td3v said:

> I believe for their operating system and their web browser Microsoft patches
> take up half or all the original size of the Microsoft product.

So? What's that actually *prove*?

> I don't have the resources to carry out this study on my own, and I know
> some folks do have those resources to release such information to the
> security community.
> 
> We need this information to be published professionally so its suitable for
> media outlet consumption.

No, you don't.

Part of the problem is that the size of the "patch" is *highly* dependent
on the details of the packaging system.  If you want to go *that* route,
you shouldn't hope to *ever* get Linux accepted.  Let's take a look at how
Redhat/Fedora package kernel "patches":

The original Fedora Core 5 kernel for a single-processor 686:

-rw-r--r--    1 263      263     14070190   Mar 14 23:23   kernel-2.6.15-1.2054_FC5.i686.rpm

Updates so far:

-rw-r--r--    1 2220     2220     15433301 Jul 15 00:13 kernel-2.6.17-1.2157_FC5.i686.rpm
-rw-r--r--    1 2220     2220     15442084 Aug 10 14:22 kernel-2.6.17-1.2174_FC5.i686.rpm

Oh my *GOD*, the patches are twice the size of the original.  And it's even worse
over on RHEL 4, where they've shipped:

kernel-2.6.9-5.EL
kernel-2.6.9-5.0.5.EL
kernel-2.6.9-11.EL
kernel-2.6.9-34.EL
kernel-2.6.9-34.0.2.EL
kernel-2.6.9-42.EL

Plus others I've possibly missed.  Size of patches is 5x the size of the
original.

Why?  Because the RPM format includes a replacement of *all* the files in the
package (so that it's easily slipstreamed and install the "latest and
greatest").  IBM AIX's "installp" format only ships updated files - but this
ends up making updates a lot more challenging (it's possible to need as many as
*4* or even more separate installp files to install a particular patchlevel of
a product).

Trying to count the size of the patch also runs astray when you have a patch
that changes an API (for instance, adding a parameter to a function call).
Most of the time, this ends up meaning that software tools like 'make' will
recompile most of the package, even if only 1/5 of the recompiled files
*really* need it. And trying to trim down the list by hand to find that 1/5 is
*dangerous*, because if you miss one, you *will* have problems.  Given the
relatively cheap nature of both bandwidth and disk, most software developers
end up erring on the side of caution.

The metric you *want* to measure is what percentage of patches are themselves
defective and require patching.

Content of type "application/pgp-signature" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/