Some weeks ago, I blogged about a security bug in Windows 7’s UAC that allows malware to exploit the new auto elevation feature to run with administrator privileges without issuing a UAC prompt. A few other sites also took up this issue discovered by Leo Davidson. Ever since then I have been waiting for a response from Microsoft, and now it is out. No less a person than Mark Russinovich covered the topic in a lengthy and highly technical article in TechNet Magazine. He doesn’t explicitly mention Leo, but it is obvious that he is quite aware of this issue. Actually, it appears that he always knew about it. In other words, it is a feature, not a bug.

Microsoft officials already had made similar statements about former UAC issues. But I think this is the first article that is not just a marketing text. It explains in great detail why UAC actually is no security boundary. And this is not just about Windows 7; it also applies to Windows Vista:

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.

As I read this, you can’t really improve security on a Windows 7 machine if you set it to “Always Notify mode.” This is the first time I’ve read something like this, but it is consistent with the whole article that discusses several ways that malware can outsmart UAC.

Someone who is new to this discussion might wonder why we need UAC at all. Russinovich leaves no room for doubt that UAC’s primary goal was to force developers to write applications that require only standard user rights. And this was also Microsoft’s only concern when the company introduced auto elevation in Windows 7:

Can an application developer inadvertently or trivially depend on administrative rights by leveraging auto-elevate?

Microsoft was quite aware that malware programmers could use the auto elevation feature, but this was not really an issue. The only thing that interested them was whether auto elevation would endanger UAC’s primary goal, which is to educate developers. Because auto elevation works only for applications that belong to Windows, and because it is most likely that developers would rather fix their applications to make them work with standard users rights instead of exploiting auto elevation, UAC’s primary design goal wouldn’t be endangered.

I also understand now why Microsoft didn’t introduce a feature that would allow users to create a white list of UAC prompt immune applications. I think it is even possible that Microsoft convinced Symantec not to market its UAC tool. If users can prevent badly programmed applications from constantly issuing UAC prompts, then how can you educate the developers?

In less friendly words: At the high cost of annoying its own customers, Microsoft introduced UAC to improve Windows’ security in the long run.

I guess that few companies out there can afford such a strategy. However, I always doubted that this was the plan in the first place. And Russinovich admits it:

While it was an early design goal of Windows Vista to use elevations with the secure desktop, Windows Integrity Mechanism, and UIPI to create an impermeable barrier—called a security boundary—between software running with standard user rights and administrative rights, two reasons prevented that goal from being achieved, and it was subsequently dropped: usability and application compatibility.

So UAC was originally planned as a real security feature and ended as an “educational feature” because the project failed. Can you imagine how badly Vista would have been bashed if Microsoft had pushed its original plan through? The compatibility and usability issues many Vista users experienced in its early days would probably be harmless compared to the ones with the Windows that Russinovich sketched here.

The main problem with Microsoft’s strategy is that this educational campaign won’t reach retired developers whose legacy applications will still be required for many years to come. Thus, the question is, do you, as an “innocent” Windows administrator, want to continue suffering under Microsoft’s educational measure? Knowing now that malware can outwit UAC easily anyway, you also could disable the UAC prompts.

You might object that Russinovich said only that UAC is no security boundary, but it is still a security barrier. A security boundary is an impenetrable security barrier. I don’t know if there is such a thing as an impenetrable barrier; however, UAC prompts certainly can prevent “legacy malware” from being executed. But such outdated malware probably will die out soon, and most antivirus tools can cope with it anyway.

As far as I am concerned, I finally disabled the UAC prompts on my own machine after reading Russinovich’s article. However, I definitely decided to complain anyway about these maddening UAC prompts whenever I meet a Windows developer. If you like, then you can follow my example and continue writing e-mails to software vendors complaining about UAC prompts. That way, UAC’s primary design goal still will be reached.