New Windows .LNK vulnerability

[Queue]

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.

I'll get around to releasing my solution eventually, it just hasn't been very high priority for me to finish things up considering the small attack surface for 9x (for this exploit), lack of interest in attacking 9x and the general misinformation concerning 9x's vulnerability to the LNK exploit.

Queue

[Guest wsxedcrfv]

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.

Ok, that makes sense (it explains what 5eraph was seeing) but it doesn't make sense from a distribution POV. Why distribute a single file in the form of a jigsaw with various pieces that has to be reassembled instead of just supplying the finished intact file?

So these 13 SFX files (one of which is some sort of main or root file) are reassembled to form shell32.dll. What's not clear to me is if this IDP package is the same package for ALL versions of windows, or if there is a different IDP package for each windows version. If a single IDP package can unpack itself and create the correct version of shell32.dll for the version of windows that it's running on, then there is a certain efficiency in doing that. But if each version of windows needs it's own IDP package, then I fail to see why it makes sense to distribute the updated file as a jigzaw puzzle that needs to be assembled by the client.

I would have thought that a significant portion of the old and new files (the original shell32.dll and the updated version) would have shared exactly identical binary sequences, hence my reasoning that it's only necessary to transmit the differences between the old and new files. That's what I thought the IDP mechanism was created to accomplish. Now I see that it doesn't even do that, so I can't see how it accomplishes any saving at all when it comes to bandwidth.

[CharlesF]

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).

Those patches are SFXCAB archive EXE files,

which WinRAR, Winzip and other archiving utilities can NOT recognize properly.

It's NOT an IEXPRESS archive EXE file like the Win9x hotfix packages.

They need to be run with the /X switch on a Win2k/XP/2k3 machine to extract the files.

Choose a folder where to extract the files and click OK to continue.

[loblo]

Could this vulnerability be in any way related to this rather fishy (IMO) little known ability of shortcuts?

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

README file for the Blesslnk.exe Tool of the Internet Client SDK

For Microsoft Windows 95 and Windows NT

December 1997

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

© Copyright Microsoft Corporation, 1997

Description

===========

Blesslnk.exe is used to add special information to the end of a shortcut

to allow Internet Explorer versions 4.01 and above to check the registry for

an update of the software at the time of execution of the shortcut.

If an update is available, a SoftwareUpdateMessageBox is displayed

asking the user to go to a web page to read about the update.

File Location Blesslnk.exe for X86 & Alpha

===========================================

x86 - Inetsdk\bin\blesslnk.exe

Alpha - Inetsdk\bin\Alpha\blesslnk.exe

Using Blesslnk.exe

===================

Usage:

------

blesslnk.exe -l AppName FullPath

where:

----------

AppName The appname, which is the name of your application in the

Registry’s uninstall branch under

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

FullPath The path to the program’s executable

< end of document>

[erpdude8]

PS: Will Win-2K users be scratching and poking at XP patches and updates, seeing if they can make them work? (heh heh). If you ask me, Microsoft delayed the "discovery" of this vulnerability just long enough so that it happened soon after Win-2K went EOL.

not necessarily, wsxedcrfv. at least WildBill has posted an unofficial Win2k KB2286198 SHELL32.DLL LNK (MS10-046) patch here:

at least Win2000 users aren't totally in the dark.