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.
Thread beginning with comment 346400
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[6]: Not that serious
by Nelson on Sat 31st Jan 2009 18:25 UTC in reply to "RE[5]: Not that serious"
Member since:

Here's another point which disproves any argument anyone could possible have towards this:

Let's set a few things off the bat:

1) An unsigned Application requires Elevation to run
2) VBScript embedded into a malicious installer would require Elevation to run

Now, your argument is this:

If it promises nude pics of Angelina Jolie, they WILL run it!

So from that, we can make point 3:

3) The user will elevate the Application

Now, the point I'm making, the point which shatters every argument against Microsoft's judgment on this, takes 1, 2, and 3 into account.

Now, let's say the user runs the malicious program, UAC pops up, and he clicks through it (As you claim he would).

Now what happens? The Application is run in elevated mode, where UAC will not popup for that Application's lifetime REGARDLESS.

This means, once an Application has elevation, UAC does not ask it again for another action in the system.

Test this by running an Application to perform SendKeys on Vista, where UAC protects system settings.

What will happen if you run it normally? UAC will pop up and stop you. Hooray! Right? Well it gets interesting.

Now run the Application and require UAC to elevate (You can do this in Visual Studio by exporting a MANIFEST file with your Application)

What happens when the SendKeys tries to disable UAC? No dialogs? What!? How can this be?

Is it magic? No it's common sense.

The fact that Applications are required to be elevated by UAC renders this entire, ridiculous claim of an exploit to be a moot point.

You can mod this down to hide the facts, but these are the facts. This is the truth. You can test all of this on your own Vista machine if you doubt the legitimacy of anything that I say.

Take the fanboy glasses off for a change people, and look at the cold hard facts. This is nothing but a headline grabbing article to post during a slow news day.

Reply Parent Score: 5

RE[7]: Not that serious
by ba1l on Sun 1st Feb 2009 01:40 in reply to "RE[6]: Not that serious"
ba1l Member since:

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