New Windows .LNK vulnerability

[Guest]

Can someone explain why Microsoft's patch is some sort of file-modifier (performing some sort of modification to the user's existing shell32.dll) instead of just a straight file-replacement?

The purpose is to reduce update package size, but you already seem to know this.

Microsoft has been capable of "delta patching" files since 2004 according to a recent MSDN article. Frankly, I'm surprised Microsoft took so long to delta patch Windows system files. However, Windows XP and 2003 updates still replace entire files.

Edited August 4, 2010 by 5eraph

[Guest wsxedcrfv]

The purpose is to reduce update package size, but you already seem to know this.

As I mentioned, it saves about 100kb worth of bandwidth. But isin't this a lot of effort for such little in return? Why complicate the update process with a complex solution like this?

Frankly, I'm surprised Microsoft took so long to delta patch Windows system files. However, Windows XP and 2003 updates still replace entire files.

Except for this patch. Since when did bandwidth become such an issue for MS that they resorted to this? They saved 3% in data transfer by doing this.

Or is there something special about shell32.dll (is that where the product key lives?) that means every one has a slightly different copy?

[cluberti]

Can someone explain why Microsoft's patch is some sort of file-modifier (performing some sort of modification to the user's existing shell32.dll) instead of just a straight file-replacement? On XP systems, shell32.dll is about 8 mb in size, and it compresses to about 3 mb. Microsoft's solution is a 2.9 mb download - saving about 100 kb in bandwidth at the expense of a somewhat complex file manipulation process.

I'm not quite sure where you're getting your numbers, but I blew out the Win7, Vista, and XP packages to see what I could find. The XP shell32 update is ~8MB in size, the Vista shell32 update is ~11MB for x86 and ~12MB for x64, and the Win7 shell32 update is ~12MB for x86 and ~13MB for x64. All of which approximately match the file size of shell32 previously installed, for what it's worth - there's no delta patching here, it's replace (well, WinSXS and link for Vista/Win7) all the way.

[halohalo]

Even though I really don't think win-9x/me is vulnerable to this exploit, I think we have a solution here:

http://code.google.com/p/linkiconshim/

Source code:

http://linkiconshim.googlecode.com/svn/trunk/

Without KernelEX, LnkIconShim is not applicable to 98.

[Guest]

Windows XP and 2003 updates still replace entire files.

Except for this patch.

Perhaps you could provide a link to the package you mention. Those I have seen replace Shell32.dll. (XPx86, 2003x86, XP/2003x64)

[Delta patching in this instance] saves about 100kb worth of bandwidth. But isin't this a lot of effort for such little in return?

Multiply small bandwidth savings by several million PCs and you begin to see method behind the madness. But we're still not talking about a delta patch here.

Edited August 4, 2010 by 5eraph

[Guest wsxedcrfv]

Perhaps you could provide a link to the package you mention.

From here: http://www.microsoft.com/technet/security/bulletin/MS10-046.mspx

Select XP-SP3 by clicking this link: http://www.microsoft.com/downloads/details.aspx?familyid=12361875-B453-45E8-852B-90F2727894FD

And download the file WindowsXP-KB2286198-x86-ENU.exe from here: http://download.microsoft.com/download/4/0/4/40447833-BCA6-41C6-A751-71A0DF5C5A66/WindowsXP-KB2286198-x86-ENU.exe

It's 2,958 kb in size. If you take the "fixed" version of shell32.dll on a 32-bit XP-sp3 system, it's over 8 mb in size, but it compresses down to about 3,100 kb (or better, depending on the compressor).

[Guest]

OK, you have the same package I have. Type the following to extract it and see that two versions of the whole file, Shell32.dll, exist within...

WindowsXP-KB2286198-x86-ENU.exe /x

Your compression program seems to be inferior to Microsoft's standard cabinet compression. 7-Zip 4.65 can repack the entire package (all 14 files) down to 2,799 KB. It shrinks my update pack (mostly DLLs) down to around 25% of original size. Not bad for freeware.

Edited August 5, 2010 by 5eraph

[Guest wsxedcrfv]

OK, you have the same package I have. Type the following to extract it and see that two versions of the whole file, Shell32.dll, exist within...

WindowsXP-KB2286198-x86-ENU.exe /x

That file does not self-unpack on a win-98 system using the /x switch.

When I unpack the file (using winzip) I see 13 files named sequentially as "_SFX_00nn.__P", where nn goes from 00 to 12. Almost all of them are small (less than 50kb) but one is large (2.4 mb). I also get _SFX_.DLL (26 kb) and _SFX_manifest_ (1kb), and a directory named "update" that contains one file (update.ver - 1kb).

If the file WindowsXP-KB2286198-x86-ENU.exe contains an actual copy of shell32.dll that is 8-mb in size, then I can't see how to extract it.

[Guest]

That file listing seems to be typical with many file compression managers, including 7-Zip and WinRAR. The only way I know to properly extract the x86 packages is with the /x switch. x64 updates unpack nicely with 7-Zip and WinRAR, probably so they can be extracted in x86 operating systems easily. But I don't know why they'd intentionally make x86 packages so difficult.

[Guest wsxedcrfv]

That file listing seems to be typical with many file compression managers, including 7-Zip and WinRAR. The only way I know to properly extract the x86 packages is with the /x switch.

I'm thinking that the extraction process involves modifying the existing shell32.dll, and that those individual SFX files (13 of them) represent 13 sections of the file to have their code replaced by the SFX segment.

The only way to know is to somehow run it on an XP system (with the /x switch) but make it impossible for it to find or modify the system's native shell32.dll file. See if it throws up an error under in that case.

Also - Winrar and 7zip also show the same internal set of files as Winzip does.

See also: http://support.microsoft.com/kb/828030

This is probably an "Intra-Package Deltas-aware (IPD-aware) package".

Edited August 5, 2010 by wsxedcrfv

[Guest]

I don't think so. That does not explain how I can extract the XPx86 package in XPx64, which has different binaries.

Also - Winrar and 7zip also show the same internal set of files as Winzip does.

That's what I said, just posited differently.

That file listing seems to be typical with many file compression managers, including 7-Zip and WinRAR.

This is probably an "Intra-Package Deltas-aware (IPD-aware) package".

The new files are not synthesized from files currently on the system. Please re-read the first line of this reply.

Edited August 5, 2010 by 5eraph

[Guest wsxedcrfv]

This is probably an "Intra-Package Deltas-aware (IPD-aware) package".

It's not. Please re-read the first line of this reply.

In this kb: http://support.microsoft.com/kb/828030

Microsoft is saying that if winzip shows an archive with an internal structure as shown in that example, then the archive is an IDP package.

So Microsoft is distributing the patch for shell32.dll on various platforms in IDP format. It makes little sense to me for them to do that, since a compressed version of shell32.dll is practically the same size as the IDP solution.

For the IDP method to work, it must have access to a base or input file that it uses as a starting point to modify based on the IDP manifest.

Look what's contained in the file "update.ver" in the update we're currently discussing:

----------------

[sourceFileInfo]

sp3gdr\shell32.dll=304CFF53C9C9BEB03607ABE94A8FC781,000600000B541782,8462336,SP3GDR,A1A5FEBC

sp3qfe\shell32.dll=B65D8CE7C75835906CD21C974B875503,000600000B541782,8463360,SP3QFE,04E2CE06

---------------

Looks like checksum information for the expected source file to be modified. If the source file doesn't contain one of those checksums, then I'm thinking the update will abort or display an error. It can't possibly generate the desired output file if it doesn't have access to the intended base input file.

Edited August 5, 2010 by wsxedcrfv

[Guest]

I feel like we're playing "Dueling Banjos", except with edits. LOL

You did not read my last edit.

It can't possibly generate the desired output file if it doesn't have access to the intended base input file.

Yet I don't get an error when extracting the XPx86 package in XPx64, which still has different binaries. And my extracted files match those found in several update packs on RyanVM.net. How can you explain that?

Edited August 5, 2010 by 5eraph

[dencorso]

The problem, with all due respect, is that wsxedcrfv is interpreting erroneously how IPD works.

There always is, inside the package, a bigger compressed file... in the present case (KB2286198 for XP), this is _sfx_0003._p (2,520,543). This file is the one which, after being decompressed, is used as the base, from which all the others in the package are generated by patching. Which name has the bigger file changes from package to package, and I don't know how the base file is recognized (maybe just by size). In other words, all IPD packages contain exactly one compressed base file and patterns to modify it to create all the others. That's all. KB828030 is one example of MS documents which are terse to the point of being misleading, because one of the files is not a delta, but instead the reference on which the deltas are applied as transforms. If you dont believe me, try to unpack one such file for XP while on Vista or Win 7: neither contains any XP files, and yet the result of the unpacking operation is the same when the package is unpacked under either Vista or Win 7, and is identical to the result obtained in XP (any SP, BTW). You can get the same results under Vista PE and 7 PE, too. This proves categorically that no file from the underlying OS is used as the reference, and is consistent with the description I just gave of how IPD works.

[Guest]

That makes sense, and seems to be scalable when multiple files need updating at once; multiple base files would be necessary or the delta code would be prohibitively large. It also explains why self-extraction would fail under Win9x—Windows Installer 3.0 is required, but not available as a backport to the older OSes.

What doesn't make sense to me is that they haven't done this with x64 updates for XP/2003.