Home page logo
/

fulldisclosure logo Full Disclosure mailing list archives

Re: Microsoft product vs Microsoft patch
From: Ajay Pal Singh Atwal <ajaypal () bbsbec org>
Date: Fri, 25 Aug 2006 08:54:25 +0530 (IST)

Ahhh well maybe we are forgetting the actual **for_real_men** technique for patching vulnerabilities and problems that 
can only be applied to GNU/ Linux like systems.

The diff files (aka patch files), applied directly to the source code, can you match their efficiency in terms of 
bandwidth.

Sincerely

Ajay Pal Singh Atwal

 
----- Valdis Kletnieks <Valdis.Kletnieks () vt edu> wrote:
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.

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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]