There is an interesting debate going on between Microsoft and two bloggers (Long Zheng and Rafael Rivera) who both claimed that they found serious vulnerabilities in Windows 7 UAC. When I read about the first UAC security flaw and Microsoft's response to it, I thought this issue would be settled. Only after I had a closer look at the second security issue did I realize that Windows 7 Beta UAC has indeed "vulnerabilities by design".
- 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
The whole discussion is about the new UAC setting "Notify me only when programs try to make changes to my computer". It is the default configuration what makes this issue even more problematic.
The first Windows 7 UAC vulnerability
The main point about the first vulnerability is that third party software is able to disable UAC without giving UAC the chance to prompt the user for consent. Rafael Rivera wrote a proof-of-concept VBscript program that demonstrates how malware could disable UAC. Basically, the program emulates a sequence of keyboard inputs that turn off UAC.
This is not invisible to the user though. If you start the script, you will see a couple of windows flare up, and at the end, Windows displays a systray notification that informs you that you have to "restart to turn off User Account Control".
Microsoft's response was that this is a feature and not a bug. The idea behind the default UAC setting is that the user won't be bothered with a UAC prompt whenever they change a Windows setting. Because the UAC settings are obviously Windows settings, you should not see a UAC prompt when they are changed. Furthermore, in order for the malware "to have gotten on the box, something has already been breached (or the user has explicitly consented)".
In my view, Microsoft's arguments are not valid. The user's only "explicit consent" would be to simply launch the program. But this is exactly the situation we now have in Windows XP. A user who belongs to the administrator group just has to launch malware to manipulate the system. Let's assume that it is possible to write a program that is able to turn off UAC in the background without displaying anything on the screen (like the proof-of-concept code); I don't see then how the default Windows 7 UAC setting brings any extra security compared to Windows XP. Hence, the default setting makes UAC more or less useless.
The only hope you have is that the malware is stupid enough not to disable UAC before getting to work. Since it is extremely easy to circumvent this obstacle, it’s like keeping your door unlocked and hoping that a thief might not know how to use a door handle.
The second Windows 7 UAC vulnerability
The second vulnerability is even more severe because it demonstrates that malware can outwit UAC without even having to disable it. When the default UAC setting is on, Windows 7 checks the embedded certificate of a program and whether the new autoElevate flag is set to decide if a UAC prompt is required or not. The problem is that there are a few Windows programs that have this autoElevate flag and also have the ability to launch other programs. Because Windows passes the administrator privileges from the parent process to the child process, malware can misuse these Windows programs to launch its own code having administrator rights without issuing a UAC prompt.
Rafael Rivera again wrote a proof-of-concept. He uses a proxy application, which he called Catapult.exe, that launches Cake.dll. With the default UAC setting, Windows will run Cake.dll with admin privileges without issuing a prompt. You can verify that if you set the UAC setting to "Always notify me". If you start Catapult.exe with this configuration, you will get a UAC prompt.
Jon DeVaan responded to both issues in Microsoft's Engineering Windows 7 blog. If I understand him correctly, then his main argument is that the term "vulnerability" is restricted to flaws that allow malware to get running without the user's consent. If you explicitly launch a program that contains malware, you have already given your consent. Therefore, we should not talk about a vulnerability here. His other argument is that there are other new defense mechanisms in Windows 7 that prevent malware from getting on the PC on the first place.
The second argument sounds very strange to me. If you don't lock the door of your flat because the house door is locked, then someone obviously wasted money on buying a lock for your door. Therefore, Microsoft wasted money on implementing this new UAC setting because it is rather useless. It also doesn't make much sense to start a discussion here about the true meaning of the word "vulnerability".
One thing is for sure, the default UAC setting in Windows 7 is a design flaw. Let me repeat what this setting is supposed to do: "Notify me only when programs try to make changes to my computer". Obviously, UAC can't keep this promise. In both the aforementioned cases, a program can make changes to my computer without a UAC prompt. Thus, the correct description of the setting would be "Notify me only when non-malware programs try to make changes to my computer".
Subscribe to 4sysops newsletter!
Update: Microsoft acknowledges the Windows 7 UAC flaw and will correct it in the Release Candidate