Not too long ago, we ran a story informing you of how the auto-elevation feature in Windows 7 is broken in a way that allows malicious programs to silently gain administrative privileges. We wondered if Microsoft was ever going to fix this one before Windows 7 goes final, and even though we’re not there yet, a recent article by Mark Russinovich seems to imply pretty strongly that no, Microsoft is not going to fix this.
After lots and lots of user complaints about how people were annoyed by UAC prompts in Windows Vista, Microsoft gave in to the whiners, and created something called auto-elevation, which allows certain parts of the system to auto-elevate themselves without bringing up any UAC prompts. This way, Microsoft was able to bring down the amount of prompts.
A clever programmer – not a security researcher – quickly found out that this was a pretty braindead decision by Microsoft, as it is now possible to quickly, easily, and silently bypass UAC completely by anything injecting code into the memory of another process, a process with auto-elevation capabilities, using standard, documented APIs. Some noted that this only works for administrators and not for standard user accounts, but since Microsoft still defaults to administrator accounts, that point becomes a bit moot.
The way to fix this issue is pretty simple: set the UAC slider back to its topmost, Vista-like level, which disables auto-elevation, and removing the threat completely, and as such, I always advise people to do so. The question has always been: Will Microsoft fix this?
A recent article on UAC in Windows 7 by Mark Russinovich seems to indicate that no, Microsoft is not going to fix this. First, he explains that even without auto-elevation, there are several ways malware can take advantage of unsigned executables asking for higher privileges. However, Russinovich adds, it’s hard for malware to get on the system in the first place. “Windows has many defense-in-depth features, including Data Execution Prevention (DEP), Address Space Load Randomization (ASLR), Protected Mode IE, the IE 8 SmartScreen Filter, and Windows Defender that help prevent malware from getting on the system and running.”
Still, if malware were to get on a system anyway, it could get past UAC, auto-elevation or not. He also reiterates that even without administrative privileges, malware can still do just about anything malware wants to do these days, such as joining a botnet or messing with user files, data, and input.
With this in mind, Russinovich continues, and addresses the specific code injection flaw we talked about:
Several people have observed that it’s 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. Since the code is executing in Explorer, which is a Windows executable, it can leverage the COM objects that auto-elevate, like the Copy/Move/Rename/Delete/Link Object, to modify system registry keys or directories and give the software administrative rights. While true, these steps require deliberate intent, aren’t trivial, and therefore are not something we believe legitimate developers would opt for versus fixing their software to run with standard user rights. In fact, we recommend against any application developer taking a dependency on the elevation behavior in the system and that application developers test their software running in standard user mode.
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’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.
This confused me. The methods he described all require elevation prompts to pop up at some point, while the auto-elevation code injection is completely silent. What this means is that Windows 7’s default UAC level is definitely less secure, as it introduces a method for malware and applications to elevate without ever triggering UAC – something that was not possible on Vista.
Throughout the article, Rssuinovich reiterates that UAC should not be seen as a security barrier, but no matter how often Microsoft brings this up, it still doesn’t make any sense to me. Microsoft has often stated that UAC is a security barrier, but whenever it doesn’t suit them to see it as such, they claim something else completely.
Even if they originally did not design it to be a security barrier, it does seem to be the case that it has turned out to be one. I’d say that instead of trying to convince the world that it’s not, they should just roll with it, improve UAC so that the mentioned holes get plugged, and use it to aid in marketing.
At the end of the day, Microsoft blogger Rafael Rivera said it best. “Here’s my million dollar question: If UAC wasn’t designed to ultimately protect us from anything, why does its icon resemble a damn shield?”