This article is more than 1 year old
Windows 7 UAC shutoff 'bug' leaves Microsoft unmoved
Insecure by design?
Security researchers have unearthed a potentially serious flaw in User Account Control (UAC) features in Windows 7. Microsoft is aware of the issue but is currently unconvinced it needs to make changes to the pre-release code.
UAC is a security feature introduced in Windows Vista that's designed to prompt users for permission before allowing applications to proceed. The technology is designed to put a guard against malware. However, many have found it intrusive and annoying.
Microsoft has modified the technology in beta versions of Windows 7, the next version of its operating system, to make it more palatable. Four different levels with the enhanced version of UAC mean that, among other things, routine tasks no longer ask for permission to run.
However, in making these changes Microsoft has inadvertently introduced a gaping security hole. Disabling UAC no longer generates a prompt. This means, security researchers warn, that future strains of malware might be able to silently shut down UAC, leaving users with the misleading impression the controls are still active. Security blogger Long Zheng explains:
By default, Windows 7’s UAC setting is set to 'Notify me only when programs try to make changes to my computer' and 'Don't notify me when I make changes to Windows settings'. How it distinguishes between a (third party) program and Windows settings is with a security certificate. The applications or applets which manage Windows settings are signed with a special Microsoft Windows 7 certificate. As such, control panel items are signed with this certificate so they don’t prompt UAC if you change any system settings.
The Achilles' heel of this system is that changing UAC is also considered a 'change to Windows settings', coupled with the new default UAC security level, would not prompt you if changed. Even to disable UAC entirely.
To underline his concern, Zheng has developed proof of concept code that surreptitiously disables UAC without social engineering trickery or user interaction. The code he and colleague Rafael Rivera developed emulates a sequence of keyboard inputs to turn off the guard-dog feature or reactivate it after loading up booby-trapped code.
"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," Zheng warns.
This override flaw would be easy to fix, without forgoing the benefits of the enhanced version of UAC, by forcing a prompt in Secure Desktop mode whenever UAC is changed. "This is not a fool-proof solution (users can still inadvertently click 'yes') but a simple one I would encourage Microsoft to implement," Zheng argues.
Other security blogs, such as WindowsConnected.com (here), have also picked up on the issue.
Microsoft is reportedly unconvinced the issue highlighted by Zheng is serious, responding to feedback by suggesting that the behaviour is "by design" and therefore isn't on the company's to-do list.
In the absence of a built-in modification from Microsoft, users can act themselves by changing the UAC policy to "Always Notify" if UAC settings change. "Annoying, but safe," Zheng concludes. ®