When Windows Vista was launched, it brought to the table a new feature that was supposed to safeguard the user: the User Account Control (UAC). However, the useful feature, which could be disabled, became the source of a great deal of the OS's early criticism due its warning messages which some users found irritating.
With Windows 7, Microsoft decided to switch gears and is offering a less nosey UAC in the beta version of the OS. This move was the subject to much early praise. However, it may have now backfired as a blogger Long Zheng, who runs the blog Start Something, has detailed a proof-of-concept attack against the new Windows 7 UAC.
Mr. Zheng says the attack is a vindication of Windows Vista, and evidence that the new Windows 7 approach, while more pleasing to some, is inherently insecure. He states, "This is dedicated to every ignorant ‘tech journalist’ who cried wolf about UAC in Windows Vista. A change to User Account Control (UAC) in Windows 7 (beta) to make it ‘less annoying’ inadvertently clears the path for a simple but ingenious override that renders UAC disabled without user interaction. For the security conscious, a workaround is also provided at the end. First and foremost, I want to clear up two things."
The flaw, which he calls "blatantly simple" to fix, was raised to his attention by a "security-minded 'whistleblower.'" Ignored largely by Microsoft in chatter in its Windows 7 beta feedback, the issue may be present in the retail version of Windows 7 and has been known to many for some time.
Normally Windows 7 is set with the options "Notify me only when programs try to make changes to my computer" and "Don’t notify me when I make changes to Windows settings". It uses a security certificate to determine if a program is part of Windows -- in other words, changes in the control panel don't raise warnings as they have a trusted certificate.
The "Achilles heel" as Mr. Zheng describes is that the UAC is a certified program and thus changes to it are also trusted -- even if that change is to disable it. While he admits that he had to "think bad thoughts" to come up with a way of disabling the UAC without directly tricking the user into doing it, he says it wasn't tough. He has posted a proof-of-concept VBScript, which uses keyboard shortcuts to select the UAC and then disable it. The attack works against any user who has administrative permissions (as standard users are prompted for an administrative password when changing the UAC settings).
He elaborates, "We soon realized the implications are even worse than originally thought. You could automate a restart after UAC has been changed, add a program to the user’s startup folder and because UAC is now off, run with full administrative privileges ready to wreak havoc."
He adds, "This is the part where one would usually demand a large sum of money but since I’m feeling generous, there is a simple fix to this problem Microsoft can implement without sacrificing any of the benefits the new UAC model provides."
The fix, he says is to force the UAC into a secure desktop mode, whenever the UAC is changed, regardless of its state. This, he says, while by no means foolproof, will prevent basic attempts. He suggests Microsoft adopt the fix as soon as possible.
Microsoft, however, appears to be relaxed about the topic, as it responded to Mr. Zheng that the flaw is "by design", indicating it will not be changed before release. Furthermore, as of this morning it has pulled a MSDN post about the topic which Mr. Zheng linked.
quote: Dude, without some basic tools from software providers most of us idiots would be swimming in viruses.
quote: I expect it to be safe because ethical people are supposedly at the helm, making sure of it. What do you believe? I believe, protect 100% of users, that includes protecting grandparents, protecting teenagers, protecting businesspeople... everyone.
quote: UAC prompts don't protect you from machine-compromising exploits, user privilege restrictions do. All a prompt does is ask someone twice whether they want to do what they intended. It's the user's access restrictions that causes malevolent code be impotent.