Windows 7 RC UAC security vulnerability: Auto elevation

Michael PietroforteMVP By Michael Pietroforte - Mon, May 18, 2009 - 5 comments google+ icon

Michael Pietroforte is the founder and editor of 4sysops. He is a Microsoft Most Valuable Professional (MVP) with more than 30 years of experience in system administration.

Windows-7-auto-elevation I somehow must have missed this discussion about this serious Windows 7 User Account Control (UAC) security hole (perhaps “barn door” is a more appropriate term). Leo Davidson published his findings in the beginning of February. I wouldn’t bring this up now if this UAC vulnerability had been fixed in Windows 7 RC. Note that this issue is only remotely related to another Windows UAC flaw I covered a while back. Leo was kind enough to send me his proof-of-concept program so I could try it with the current Windows Release Candidate. I must admit I was quite surprised that it really worked because it proves that the default setting in Windows 7 makes UAC absolutely useless. In my opinion, UAC in Windows 7 even reduces overall security.

I really can’t believe that Microsoft just ignored Leo’s findings. Leo has contacted the company and offered his proof-of-concept program’s source code. Moreover, major news sites such as The Register have reported this issue; thus Microsoft must be aware of this serious security problem. This indicates that there is a design flaw in UAC that probably can’t be fixed easily. Therefore, it is quite likely that Windows 7 will be released with this vulnerability.

Leo has described the vulnerability in detail, so I am giving only a brief overview here. He has proven that any program running with standard user rights (medium integrity level) can elevate another program (high integrity level) without issuing a prompt if UAC is configured with the default setting. Basically, this makes UAC useless, because its main purpose is to warn users whenever a third party application tries to modify the system. However, it is obviously easy for malware to outsmart UAC and run its own code with administrator privileges, without the user’s approval.

Leo’s proof-of-concept tool demonstrates this issue very well. The program is a standalone application that doesn’t issue a UAC prompt when launched. I used the tool to run notepad with administrator privileges. Even though I saw no UAC warning dialog when notepad started, I could save a file in the Windows system folder with it.

Leo uses the auto elevation “feature” (also called silent elevation) that was introduced in Windows 7. This feature allows Windows to elevate some system tools silently, that is, without prompting a UAC dialog. The default UAC setting (“Notify me only when programs try to make changes to my computer”) enables silent elevation. For example, when you try to change the firewall settings, you will see a UAC prompt in Windows Vista, but auto elevation prevents this in Windows 7. Leo’s tool just uses these privileged Windows processes to execute his own code. Moving the UAC slider to the top, to “Always notify,” disables silent elevation. Therefore, this security vulnerability doesn’t exist at the highest UAC security level.

What I find interesting is that Leo doesn’t consider himself to be a hacker or security expert. In fact, the technique he used is fairly simple, using only standard APIs. He describes it as code injection, but acknowledges that this term is used differently sometimes. The point is that it is only a matter of time until others will find ways to use this Windows 7 vulnerability. My guess is that malware programmers are already prepared. The bad guys usually don’t go to the public.

I have argued right from the beginning, when UAC was introduced, that security prompts with such a high false-positive rate are useless, even dangerous, because they lull users into a false sense of security. With Windows 7 this becomes even worse than in Vista. Many users keep UAC enabled because they want to know when a program tries to make system changes. In Windows 7 this reason no longer applies. Of course, most will just work with the default UAC setting, with the false belief that Microsoft certainly knows which configuration is best.

Even Microsoft’s primary goal, i.e., to coerce developers to write applications that require only standard user rights, is in danger when circumventing UAC becomes common practice. I only hope that Microsoft will change the default configuration to the highest security level in Windows 7 RTM. At least this won’t put ideas into the heads of Windows developers.

For future releases Microsoft should adapt Symantec’s UAC approach and allow users to create white lists of applications that don’t issue UAC prompts. This would reduce the number of UAC prompts significantly. After users have trained UAC, the false-positive rate will be low enough to make UAC a useful security tool. It goes without saying that this method would provide more security than this silent elevation “bug” in Windows 7.

-1+1 - Rate this post
Loading ... Loading ...
Disclaimer
Your question wasn't answered? Please ask in the new 4sysops forum!

5 Comments- Leave a Reply

  1. Jarred Fehr says:

    I agree with you here. For work and home, I will set all PCs to the highest UAC setting. So many people have complained and moaned about UAC that MS must feel it has no choice but to make it less noticable. However, I think that doing it this way in Win7 is completely undoing all the hard work and effort that went into Vista UAC. Maybe if more people (like you) point this out MS will do the right thing and restore UAC to a useful default configuration.

  2. Fowl says:

    There was a reason there wasn’t a whitelist in Vista, and it’s the same one as the built in one is 7 is a bad one.

    Anytime you put something there, you completely compromise the system. Programs just need be designed properly.

    I’m very dissapointed Microsoft completely ignored their own advice. Say waht you like about Vista’s UAC, but at least it worked!

    At least they allow you to turn it back to the “useful” setting from the “pointless prompts that anyone can get around” mode that is now the default.

  3. jon says:

    The technique described is probably more accurately termed “DLL injection” (http://en.wikipedia.org/wiki/DLL_Injection) rather than “code injection”. Actually the distinction between the two is really negligible but many people consider “code injection” to specifically mean the exploiting of a bug in the target process, where as “DLL injection” refers to the use of standard, supported system mechanisms of running your own code in the context of another process.

  4. jon says:

    (continued from above) The point being – that this mechanism DOESN’T depend on a bug in the target process, but instead uses a standard, documented system API.

  5. Jarred, I absolutely agree. UAC in Windows 7 is Microsoft’s reaction to the complaints. So perhaps we can’t blame Microsoft alone. I also belonged to those who complaint about UAC. However, I didn’t complain because I dislike the idea of separating users and admins. I just don’t like the way Microsoft tried to solve this problem. In Windows 7 Microsoft made things only worse. It is a quick-and-dirty solution.

    Fowl, whitelists certainly reduce security. However, one always have to find a trade-off between convenience and security. Auto elevation obviously was a bad choice. We already compromise our systems at the moment when we create “whitelists of users” who are allowed to logon on. Every admin will agree about that. Whitelists under Linux (sudo) were never really a security problem. Microsoft only has to copy what others are doing already for years with success.

    jon, Leo also speaks about DLL injection. However, he does not really inject a DLL. Perhaps “EXE injection” would be more appropriate. I am not sure if we shouldn’t talk about a bug here even though only standard APIs are involved.

Please share your thoughts in a comment!

Login

Lost your password?