Cupfighter.net

Win 7 UAC Code-Injection: Summary

On 5th February 2009 I wrote a proof-of-concept program to demonstrate a security flaw in Windows 7′s UAC, under default settings with beta build 7000 (also confirmed on 7022). This simply copied a file to Program Files without the user’s consent. In other words, it performed a file copy to a protected location, bypassing UAC.

“So what? All it does is copy a file?”

On 9th February 2009, to show the implications of being able to copy to System32 and Program Files, I created a second proof-of-concept program which uses the original exploit to open up a hole which in turn allows it to run any command or program with full elevation without itself requiring elevation or the user’s consent.

All of this is done without using the SendKeys or RunDll32 holes which were found earlier in February. It is done using a method which can attack almost any Windows executable and which is inherent to the changes Microsoft have made to UAC in Windows 7.

The proof-of-concept works on unmodified installs of Windows 7 beta build 7000 (and confirmed on 7022), both 32-bit and 64-bit versions, at default settings.

Setting UAC to its highest level, or using a non-admin account, will prevent the proof-of-concept from working by forcing it to display a UAC prompt. However, neither of those are defaults in the current Windows 7 betas.

As well as discussing the proof-of-concept code I argue that:

• Microsoft should either admit that local process elevation is a problem and make Windows 7 more secure by default or admit that the Windows 7 default UAC settings are security theater (as they offer no protection) and anti-competitive (as they are inflicted on third-party code despite local elevation supposedly being a non-issue).
• If there is to be a UAC whitelist, or the equivalent of one, then it should be up to the user which Microsoft and third-party software is on it. Users should not be forced to expose themselves to risks from software they do not use. Conversely, if reducing UAC prompts in frequently-used software is needed to stop people disabling UAC entirely then that applies to third-party software as much as to bundled software (especially once a machine is past the “setup” phase).
• UAC itself was a good API and a good design that was given a bad name because of the way it was used by Microsoft’s application-level code (such as Explorer and Control Panel). Accordingly, the user experience of having UAC enabled could have been vastly improved by changing the application-level code without opening a huge hole in UAC.
• Microsoft created these problems themselves and, rather than fixing them properly, have taken the easy way out, unnecessarily making UAC less secure in the process. At the same time Microsoft expect third-party vendors to do a better job than they bothered to do using the API which they themselves designed.

If you’re already shouting, “But it’s only a beta!” then there’s a section for you, too.

And, for the record, I like Windows and much of what Microsoft do, in general. I even like UAC (the API, not the way it has been used). I wrote this page because I care about the platform not because I get a kick out of attacking something Microsoft have done. I call things as I see them. I attack and criticise some of what Microsoft do and I support and defend Microsoft other things that they do.