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.
- Pip install Boto3 - Thu, Mar 24 2022
- Install Boto3 (AWS SDK for Python) in Visual Studio Code (VS Code) on Windows - Wed, Feb 23 2022
- Automatically mount an NVMe EBS volume in an EC2 Linux instance using fstab - Mon, Feb 21 2022
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.
Subscribe to 4sysops newsletter!
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. 😉
“So UAC was originally planned as a real security feature and ended as an “educational feature” because the project failed.”
You’re mis-interpreting Mark’s statement. UAC was one part of a set of tools whose end goal was raising the security posture of Windows. The tools providing the real barrier were integrity levels and UIPI. UIPI ad integrity levels were deemed too disruptive and thus removed and the security barrier with them. UAC was a complementary tool that furthered the goal. And if you re-read the statement, he doesn;t even mention UAC, even though the context of the statment is within a UAC discussion, the specifics do not include UAC.
Also note that UIPI and and integrity levels are actually still in the product, they are just not utilizied.
The question I always have for folks who find UAC so annoying is what are you doing to get the prompt all the time? I’ve run Vista since early betas at home and work and rarely see a prompt unless I’m expecting it. The great thing is that I haven’t run using an admin account since before XP so UAC prompts me for credntials without having to remember to use Run As – which btw doesn’t work the same in Vista anyway so doesn’t work at all if you disable UAC.
It still ignores the fundamental problem with UAC – the average user doesn’t have a clue whether to say yes or no in response to a UAC prompt. It’s not that obvious to more seasoned users, either.
Jason, I am not interpreting, I am just concluding. The point is that Microsoft had bigger plans, and these plans failed. All that is left is not a security feature, but an educational feature. My main point in this article is not that the UAC prompts are disturbing. It is just that their purpose is a different one than many believe. They are not supposed to warn you about malware, they are supposed to tell you that the developer of this program has to be educated.
Phil, I agree. UAC messages should be more explicit. What about this one: “Inform the developer of this program that you don’t like this prompt!” 😉
Michael, Then I completely agree with you.
Phil, The average use can barely turn on a PC. If you stop to actually read the prompts, they have always clearly stated that the action you are attempting to perform is privileged. If you drive a car, you learn to put gas in it, check the tires, change the oil, don’t drive over 80 in the snow, etc. Why is it so much to ask for users to actually read the message?
Why are some actions privileged? This is more of a legitimate gripe and Microsoft has been working hard to reduce the privileges on many actions that shouldn’t require elevation.
The fundamental problem is not with UAC, its with application developers who have failed to adhere to Microsoft standards that have been published since NT 3.51. If you run *nix or OS X, normal users have never run as root. Windows was designed the same way, its just the mass of developers out there never cared to learn the proper way of doing things.