UAC in Windows 7 still broken, Microsoft won’t/can’t fix code-injection vulnerability

admit, as a non-programmer, I have very little knowledge about the inner-workings of Windows. However, as an enthusiast, I thought I had a basic but firm understanding of what User Account Control is, how it works, and why it exists. That’s no longer true. After reading reading an article by Windows-god Mark Russinovich, "Inside Windows 7 User Account Control", I’m bewildered by the changes to UAC in Windows 7.

At first, Mark provides this logical explanation for UAC elevation prompts.

Elevation prompts also provide the benefit that they “notify” the user when software wants to make changes to the system, and it gives the user an opportunity to prevent it. For example, if a software package that the user doesn’t trust or want to allow to modify the system asks for administrative rights, they can decline the prompt.

Bearing this in mind, you’re probably familiar with the commotion raised months ago over a concern over how applications can silently turn off UAC prompts in Windows 7 which Microsoft addressed (after a fair dose of community effort), but what you might not know is that there is another and more serious “exploitative” UAC vulnerability breaking exactly what Mark described.



The other UAC exploit, discovered, demoed, extensively documented by Leo Davidson, is a code-injection vulnerability made possible by the new Windows 7 auto-elevation system. To summarize War and Peace into a short story if you will, it allows applications without UAC prompts (medium-level) to run code or other applications with administrative privileges (high-level), assuming the default security configuration in Windows 7 (don’t notify changes to Windows).

It was my original intentions to not publically address this until Windows 7 has been finalized, giving them an opportunity to fix it, but Mark’s article today tells me they’re doing no such thing.

Knowing the vulnerability, I was of surprised to see the article conclude with a direct reference to this exploit.

Several people have observed that it’s possible for third-party software running in a PA account with standard user rights to take advantage of auto-elevation to gain administrative rights. For example, the software can use the WriteProcessMemory API to inject code into Explorer and the CreateRemoteThread API to execute that code, a technique called DLL injection. [...]

The follow-up observation is that malware could gain administrative rights using the same techniques. Again, this is true, but as I pointed out earlier, malware can compromise the system via prompted elevations as well. From the perspective of malware, Windows 7’s default mode is no more or less secure than the Always Notify mode (”Vista mode”), and malware that assumes administrative rights will still break when run in Windows 7’s default mode.

Ultimately Mark dismisses the exploit and that’s where he lost me.

Mark points out though, excluding this vulnerability, there are actually other known methods for malware to compromise the system via elevation exploits, a flaw in the UAC design. What he misses though is the fact that the problem is more serious in Windows 7 than in Windows Vista.

How these variations of elevation vulnerabilities work is that they all piggyback on elevated application with COM objects that can be exploited to run functions at elevated privileges. However, in Windows Vista, the applications that can be piggybacked on would have displayed a UAC prompt at one point or another to elevate, whereas in Windows 7, there are known Windows executables that can be launched, silently elevated and piggybacked on.

What’s more is that this applies not only to malware but to any application. By that I mean legitimate developers can write applications that take advantage of this code-injection vulnerability to make their applications run in administrative privilege without UAC prompts. Of course, the likelihood of this is low, but not impossible. For example, competing softwares could leverage this to make their software appear “less annoying”. If you’re having to doubt if an application is following the rules, it would damage the reputation of the whole ecosystem.

Putting the “security barrier” jargon aside, I argue as a direct result of the auto-elevation white-list, the UAC in Windows 7 by default is fundamentally less secure than Windows Vista’s default. I recognize that UAC was not designed to be a “security feature” to begin with, but with each new version, an operating shouldn’t become less secure and expose more risk to the user.

Granted it is highly unlikely Microsoft is willing to revert Windows 7 to UAC-prompt-hell, what they can and should do is communicate that there is a difference in security between the Windows 7 default UAC setting and the “Always Notify” mode. If users then accept the increased risk, then they should be able to enjoy a less annoying Windows.

Thoughts?