A short couple of weeks ago, I criticized Microsoft's "Ten Immutable Laws of Security." The so-named Ten Laws leave Microsoft shielded from users who will be going approval-crazy under User Account Control (UAC) because they either don't know for sure how to respond to the dialog, what they did to cause the dialog to come up, or whether they really want to do whichever action is happening. I particularly criticized the "If a bad guy can convince you to run software on your computer..." law, which seems like such a broad statement when examined. What happens when Aunt Gladys gets a new photo gallery from her favorite son in law and it turns out to be a Trojanned executable, but the message is believable enough to be run (all of you have Aunt Gladys in your family; don't deny it).
I found that a feature of the Windows Vista shell (in fact, part of Windows XP's shell too) - specifically, the Start Menu interface, presents an opportunity for exploitation of users, as does the desktop and any other part of the user's directory structure. You see, all of the user folders - including the Desktop, parts of the Start Menu, Documents folder, Music, Videos, Application Data - each user folder is writable by the user to whom it belongs. Further, the Start Menu synthesizes the All Users and user-specific Start Menu folders (have you ever seen an installer that asked if you'd like to install a program just for yourself or all users of the machine? This is an example of where that answer is applied) are combined, with the user's folder taking precedence, to form the composited Start Menu presented by the shell.
Utilizing my exploit, untrusted code in a vector such as a Trojan could replace shortcuts from the Desktop and the user's Start Menu folder - the Start Menu folder by duplicating shortcuts from the All Users folder - and putting the duplicates in the user's folder.
This may not be a major difficulty for the enterprise, where system policy can require signed executables and the like. However, for the home user, where such a requirement will likely be neither common nor practical, and untrusted code is run commonly as part of downloads or necessary software, or (especially) targetted ad software, this can become a severe issue. To add to the issue, Microsoft released with every edition of Windows Vista the .NET Framework 3.0, which runs on the 2.0 CLR, which means that an application compiled and targetted for the 2.0 CLR. This in and of itself is not a major issue; what is, however, is the ease of which a custom stub executable can be generated. Why is this necessary?
This exploit works because the yellow UAC dialog for unsigned executables does not display the full path to the target executable by default, and makes no distinction between a program run in a UAC-protected path and a non-protected path. Let's take the World of Warcraft executable (WoW.exe), which is not signed, as an example - I'm using it because it occasionally requires elevation to patch itself, and it has a large install base (and so many people have heard of it). When your computer is first infected by the attack vector, the shortcut to WoW.exe (in c:\Program Files\World of Warcraft\) on the Start Menu is replaced by a new shortcut by using the IShellLink COM interface to save the shortcut to the user's Start Menu folder. Utilizing the System.CodeDom namespace of the .NET Framework, it is exceedingly easy to generate a stub executable that launches a DLL by pulling it out of a resource file and then launch the original target process. The newly-created executable is saved to a subpath of the user's AppData path, where the user has full write access.
By detecting at infection time whether a shortcut's target executable is signed, we can make it difficult to detect that the user's account has been infected. Since only unsigned executables display the yellow UAC dialog that doesn't ever display a publisher or any additional file metadata (including the icon resource), we need to only use the WinVerifyTrust API (see my previous post) to determine whether a Start Menu or Desktop item is a candidate for replacement.
Going back to the World of Warcraft example, the infection vector enumerates the WoW.exe shortcut on the All Users Start Menu path, determines that WoW.exe is unsigned, creates a stub EXE to check for the presence of the "Administrator" role and load the malicious software, and then launches the original task. Thus, when Warcraft needs to be patched, the user will elevate the WoW.exe shortcut via the Start Menu or the Desktop, and the malicious code will then have full access to the operating system.
In e-mail from a Microsoft representative, Microsoft does not consider this to be a privilege elevation exploit, and so will not be responding to the threat. That's really too bad - perhaps security corporations will be able to deal with this better.
For full details on the exploit, you can download the whitepaper and proof-of-concept code. It was also posted to Bugtraq, but that post is much less-detailed than this one.