Windows Vista 7 Normal Taskbar Windows 7 UAC code-injection vulnerability: video demonstration, source code released
Jun 11

I 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鈥檚 no longer true. After reading reading an article by Windows-god Mark Russinovich, 鈥淚nside Windows 7 User Account Control鈥, I鈥檓 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 鈥渘otify鈥 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鈥檛 trust or want to allow to modify the system asks for administrative rights, they can decline the prompt.

Bearing this in mind, you鈥檙e 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 鈥渆xploitative鈥 UAC vulnerability breaking exactly what Mark described.

win7elevate

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鈥檛 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鈥檚 article today tells me they鈥檙e 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鈥檚 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鈥檚 default mode is no more or less secure than the Always Notify mode (鈥漋ista mode鈥), and malware that assumes administrative rights will still break when run in Windows 7鈥檚 default mode.

Ultimately Mark dismisses the exploit and that鈥檚 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鈥檚 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 鈥渓ess annoying鈥. If you鈥檙e having to doubt if an application is following the rules, it would damage the reputation of the whole ecosystem.

Putting the 鈥渟ecurity 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鈥檚 default. I recognize that UAC was not designed to be a 鈥渟ecurity feature鈥 to begin with, but with each new version, an operating shouldn鈥檛 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 鈥淎lways Notify鈥 mode. If users then accept the increased risk, then they should be able to enjoy a less annoying Windows.

Thoughts?

Random Posts

One Response to “UAC in Windows 7 still broken, Microsoft won鈥檛/can鈥檛 fix code-injection vulnerability”

  1. I Make Thousands of Dollars a Month Posting Links on Google from Home Says:

    Hey, nice post, very well written. You should write more about this.

Leave a Reply

*
To prove you're a person (not a spam script), type the security word shown in the picture. Click on the picture to hear an audio file of the word.
Click to hear an audio file of the anti-spam word

Powered by Love Windows7