Linked by Thom Holwerda on Sat 31st Jan 2009 10:45 UTC
Privacy, Security, Encryption Yesterday, we reported on the security flaw in Windows 7's UAC slider dialog, and today, Microsoft has given a response to the situation, but it doesn't seem like the company intends to fix it. "This is not a vulnerability. The intent of the default configuration of UAC is that users don't get prompted when making changes to Windows settings. This includes changing the UAC prompting level." I hope this reply came from a marketing drone, because if they intend on keeping this behaviour as-is in Windows 7 RTM, they're going to face a serious shitstorm - and rightfully so. Let's hope the Sinfoskies and Larson-Greens at Microsoft rectify this situation as soon as possible.
Permalink for comment 346447
To read all comments associated with this story, please click here.
RE[7]: Not that serious
by ba1l on Sun 1st Feb 2009 01:40 UTC in reply to "RE[6]: Not that serious"
ba1l
Member since:
2007-09-08

Nelson - you don't understand how this works. There are no UAC prompts AT ALL. Anywhere. That's the problem.

In Windows 7, an admin user does not see UAC prompts when they try to change Windows settings like they do in Vista. There's a set of applications (like the Control Panel applets) which have a specific digital signature on them, and UAC allows these applications to be elevated without prompting the user.

As on Vista, you do not need to authorize an application to run using a UAC prompt. Normal applications will simply run with user-level permissions.

As on Vista, an application that's marked as requiring elevated permissions, or an application that attempts to do something requiring elevated permissions, will trigger a UAC prompt.

This exploit does neither. It will simply run as any admin user (like the default user everyone uses). There are no UAC prompts, because it isn't flagged as requiring UAC, and doesn't try to do anything it's not allowed to.

The exploit opens the UAC control panel (which is signed by Microsoft), turns UAC off using keyboard shortcuts, and then closes the control panel.

At this point, the user hasn't seen any UAC prompts, and UAC has been turned off, probably without them knowing about it.

The exploit could then do anything that would normally trigger a UAC prompt, such as installing drivers, changing system settings, and so on. I could even turn UAC back on after it's finished.

The point is that it allows an application to completely bypass UAC without the user seeing any kind of warning.

When designing UAC in Vista, they obviously thought about the problem of applications manipulating the UAC dialogs using keyboard shortcuts. That's why the UAC prompts appear on a separate desktop - they can not be manipulated in this way.

Apparently, whoever implemented the silent UAC system in Windows 7 wasn't as careful, and didn't think about a rouge application abusing keyboard shortcuts to change settings it's not allowed to.

Basically, applications that are running at higher privlege level shouldn't be able to be manipulated by lower applications. But they can be, as long as they're running on the same desktop.

It could even be worse. What happens if you run one of these control panel applets, and then inject a DLL into it?

Reply Parent Score: 0