Hacker, Microsoft duke it out over Vista design flaw
Rutkowska, a hacker with a track record of defeating Vista's security mechanisms, believes UAC has a major flaw in the way it automatically assumes that all setup programs (application installers) should be run with administrator privileges.
"[When] you try to run such a program, you get a UAC prompt and you have only two choices: either to agree to run this application as administrator or to disallow running it at all. That means that if you downloaded some freeware Tetris game, you will have to run its installer as administrator, giving it not only full access to all your file system and registry, but also allowing it to load kernel drivers! Why should a Tetris installer be allowed to load kernel drivers?," Rutkowska asked in a post on her Invisible Things blog.
That's because Vista uses a compatibility database and several heuristics to recognize installer executables and, every time the OS detects that an executable is a setup program, "it will only allow running it as administrator."
This, in Rutkowska's mind, is a "very severe hole in the design of UAC."
"After all, I would like to be offered a choice whether to fully trust given installer executable (and run it as full administrator) or just allow it to add a folder in C:Program Files and some keys under HKLMSoftware and do nothing more. I could do that under XP, but apparently I can’t under Vista, which is a bit disturbing," she added.
A few days after Rutkowska flagged the UAC shortcoming, Microsoft's Mark Russinovich wrote a detailed technical explanation of the way the mechanism works. One thing that stood out in Russinovich's explanation is an admission of sorts that the default configuration of UAC puts the user at risk of a sophisticated code execution attack.
Russinovich, a technical fellow at Redmond, writes:
As you experiment you’ll find that your actions are limited, but there are some design boundaries that you should be aware of. First, with the exception of processes and threads, the wall doesn’t block reads. That means that your low-IL command prompt or Protected Mode IE can read objects that your account (the standard-user version if you’re a member of the administrator’s group) can.
This potentially includes a user’s documents and registry keys. Even the ability of a process at low IL to manipulate objects of a higher IL isn’t necessarily prevented. Since processes running at different integrities are sharing the same desktop they share the same “session”. Each user logon results in a new session in which the processes of the user execute. The session also defines a local namespace through which the user’s processes can communicate via shared objects like synchronization objects and shared memory.
That means that a process with a low IL could create a shared memory object (called a section or memory-mapped file) that it knows a higher IL process will open, and store data in the memory that causes the elevated process to execute arbitrary code if the elevated process doesn’t properly validate the data.
That kind of escape, called a squatting attack, is sophisticated and requires the user to execute processes in a specific order and requires knowledge of the internal operation of an application that is susceptible to manipulation through shared objects.
Russinovich pegged it as a tradeoff between application compatibility and ease of use, explaining the weakness as a "design choice."
Because elevations and ILs don’t define a security boundary, potential avenues of attack , regardless of ease or scope, are not security bugs. So if you aren’t guaranteed that your elevated processes aren’t susceptible to compromise by those running at a lower IL, why did Windows Vista go to the trouble of introducing elevations and ILs? To get us to a world where everyone runs as standard user by default and all software is written with that assumption.
That explanation isn't sitting well with Rutkowska. In an e-mail interview, the Polish malware researcher said she was "pissed off" by what she perceived as Russinovich's flippant attitude to the potential risk.
"It seems like Microsoft realized that implementing UAC would be hard, so they decided not to call it a security mechanism anymore and that 'potential avenues of attack, regardless of ease or scope, are not security bugs'," she said, quoting directly from Russinovich's essay.
"I don't think it's fair after all this Vista security campaign we observed in 2006, where Microsoft was boasting about this new security model in Vista. This is not a proper way to solve security problems. Microsoft, instead of trying to diminish the problem, should work on the solutions (even if they expected to see a dozen of new attacks against UAC)," she added.
Rutkowska also took issue with this line from Russinovich's argument:
"[H]aving your elevated AAM processes run in the same account as your other processes gives you the convenience of allowing your elevated processes access to your account's code and data, but at the same time allows your non-elevated processes to modify that same code and data to potentially cause an elevated process to load arbitrary code..."
"This is not valid," Rutkowska declared. "If we followed this reasoning, then we would not be able to talk about security in our email clients nor web browsers, because they all also access data and code which are not trusted."
Her final thought: "I believe that the Vista security model is a good thing and that users can benefit from it, but Microsoft must change their attitude and start treating them as security mechanisms."
[UPDATE: February 13, 2007] Rutkowska wrote in to clarify a few things that appear confusing in the article above:
There are two different things, which should be distinguished:
1. The fact that UAC *design* assumes that every setup executable should be run elevated.
2. The fact that UAC *implementation* contains bugs, the one noted in the original blog entry that allows a low integrity level process to send WM_KEYDOWN messages to a command prompt window running at high integrity level.
I was "pissed off" not because of #1, I was "pissed off" because Microsoft employee -- Mark Russinovich -- declared that all *implementation* bugs in UAC are not to be considered as security bugs (see fact #2).
True, I also don't like the fact that UAC forces users to run every setup program with elevated privileges (fact #1), but, I can understand such a design decision (as being a compromise between usability and security) and this was not the reason why I wrote my follow up titled "Vista Security Model - A Big Joke".