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.
“Let’s hope the Sinfoskies and Larson-Greens at Microsoft rectify this situation as soon as possible.”
Forget it. It _is_ the drones who make decisions like these at Microsoft and no Sinfosky will be able to stop them.
You have all these developer blogs and stuff, do you really think they change MS decision making? Or where does your hope come from?
Edited 2009-01-31 12:02 UTC
So, Mr. Marketing Drone… what happens if it’s a program changing the setting instead of a user as the sample script actually demonstrated?
I can’t believe they’ve gone through all the pain with UAC in Vista to f–k up big way like this now
If you allow this script to run on a Ubuntu machine, it will disable sudo prompts for admin accounts without prompting for any password.
^M is ctrl-v+ctrl-m
– Type it and save as b00ni3s.sh
– Open up a terminal
– Type:
$ sudo chmod +x ./b00ni3s.sh # Type in your password to allow execution
$ ./b00ni3s.sh
What happens? You see dancing bunnies.
Throw your Ubuntu laptop in the bathwater and it has the risk of short-circuiting!
Don’t be an idiot. You have to intentionally destroy your computer with these steps to destroy your computer.
Not to mention, give it your password…
It doesn’t ask for further confirmation.
The(unneeded) sudo in chmod makes it so that all commands are trusted for a few minutes. If you followed my instructions no password is asked. If you didn’t follow them but had just used sudo, no password is asked.
The bottom line is: do not run scripts.
Thats the point he is making. The problem with malware is that the user does not know what it will run in the background once they allow it to run given the *first* prompt.
Yes, because sudo has cached the password from when you just executed “sudo chmod”
What happens if you chmod the script then try to run it five minutes from now? You see a sudo password prompt.
Er no, you’ll get a sudo password request. Unless of course you just ran sudo in the same terminal beforehand, which I presume you did while writing the script..
*next!*
this is why some malware makers do what they do. some people feel compelled to force people to see the truth.
if this is actually exploitable, it will be exploited. and if it is exploited well, it will probably be fixed. and we’ll all look back and give a chuckle, “OH MICROSOFT! :-)”
People complained loudly that UAC is annoying and prompts to often. MS put the control in the users hands, made it adjustable because people made such a big deal over the UAC in Vista. So what do people do now, when UAC is broken by the default settings in Win7? More complaining. It can be changed, you know.
You people made your bed, lie in it.
This is a fascinating evolutionary step. We’ve moved beyond blaming users for going to bad websites, installing unrecognized programs, and not keeping their drivers up to date. Now we’re actually blaming users for executive design decisions of the software vendor!
It’s disturbing that the first line of the exploit article says it’s the tech journalists who cried wolf, when that is precisely what UAC does to get people so annoyed. It’s no one’s fault but Microsoft’s that UAC was designed after Homer Simpson’s “everything’s fine alarm.”
People complained about a severe usability flaw, and Microsoft substituted in a severe security flaw. What lesson would you have us take from this?
So you think there are only two options here? UAC prompts users a lot or UAC doesn’t prompt users.
If people are complaining about both options then that should tell you that neither option is a good option.
People want security without having to think about security…that’s the problem that needs solving.
Easy!
Use OpenBSD…. problem solved!
No thinking needed – secure by default.
Edited 2009-02-01 05:52 UTC
…that’s not really true. OpenBSD suffers from the same problems as most of the Unixes and other major operating systems. OpenBSD has no known remotely exploitable bugs in it’s default install(which is a state of complete uselessness)…but as soon as you actually use if for something you have to start thinking about the security implications.
There are ways to do ‘no thought security’ it’s just that it’s a lot of effort to setup because you have to break backwards compatibility.
I really have to challenge this statement. I think that this thing that you call ‘no thought security’ (a nice term, by the way!) is not achievable at all, if you want to keep the computer system useful. It’s not just ‘a lot of effort’, as you call it, it’s rather that before we get to the point that “no thought security’ becomes reality, a lot of research would have to teach us much more about user psychology, work flow, expectations in human-computer-interactions, etc. than we know today.
Otherwise, one would have to artificially restrict what the user is able to do just to protect them. If that’s what you label ‘no thought security’, then we certainly do agree!
Anyway, if you could provide any more insight about ‘no thought security’ or some external sources, it would be appreciated!
It is not broken, it is a feature :p
BluenoseJake trolled…
Errr…no. What we complained about was the joke UAC was made into, with even Microsoft itself admitting it was made purposely to be annoying not useful. Don’t believe me? do a search on this very site, this was where I first saw the article.
Now if UAC had worked like Ubuntu handles accounts, with requiring an administrator password before proceeding then you wouldn’t have seen quite as many complaints on here and elsewhere about it. (I don’t say you wouldn’t have seen any complaints because we both know there are some people who will never be happy with what Microsoft does no matter what it is.) The problem is instead of requiring escalated privileges UAC behaves like Clippy on steroids prompting:
…and ultimately resulting in absolutely no change in behavior.
Most users turn it off first thing, and the ones who are unable to do so just click through it without reading it, making the problems UAC was supposedly intended to fix worse!
I’m not saying any of this would fix the current problem, but pretending this is a case of people complaining about UAC without merit is simply trolling and you know it.
–bornagainpenguin
Screenshots or it didn’t happen.
UAC was a success, as the number of applications requiring admin privileges has been drastically reduced. THAT was its intended goal, and it succeeded.
Thom_Holwerda disputed…
That may have happened as a result, but let’s be honest here–it was a nice side effect. For it to have resulted in the changes you suggest would have to mean most users of Windows are running as limited accounts. I don’t think anyone wants to pretend that’s happened–for the very same reason you point out: ‘Everyone’ knows installing apps requires admin privileges and so run that way as default.
–bornagainpenguin (who has yet to see a Vista installation in the wild not running with admin privileges)
I think you need a lesson on how UAC works.
UAC is not only effective when you run a LUA; admin accounts are protected as well. Admin users have to click “ok” when something requires elevated permissions, LUAs have to enter the password.
The goal, as clearly stated by Microsoft, was to annoy users so much, that they started demanding that 3rd party developers fix their apps so they don’t need admin priveleges anymore.
As the dramatic reduction in the number of applications requiring admin privileges shows – this goal has been achieved.
That’s the beauty: people running as admin are still protected because unauthorised access will still be picked up. Of course, running as non-admins is preferred, but oh well.
So, your argument falls flat: whether you’re on a LUA, or an admin account, you get the same amount of prompts. In other words, the amount of prompts isn’t forcing anyone to stick with an admin account.
I haven’t used Vista all that much. I have a problem in principle with a version of Windows that is a minor enhancement at most for me (vis-a-vis XP) taking twice or more the resources. But when I’ve used it, I haven’t found UAC all that annoying. The only time I didn’t like it was when performing file operations in Windows Explorer that required privileged access. Explorer prompts once, then UAC prompts again. It’s a drag if you are creating directories under C:\ or C:\Program Files. But overall UAC wasn’t much worse than sudo on *nix to me.
Wow, if that be the case, that’s rich. They don’t have enough cojones as a multi-billion-dollar company to apply the pressure on their ISVs themselves? Besides, sometimes those 3rd-party apps are felt to be indispensable, or the vendors don’t listen–sort of like with, um, oh yeah, Windows and Office. [I would not often use the term “alacrity” to describe the pace at which Microsoft has addressed user complaints.]
All that said, I’m running non-admin on XP, when I do run XP. With a few tweaks (mostly to allow me to adjust wireless settings, since wireless on XP still sucks), it isn’t all that bad, either.
People seem to overlook the fact that, for this to even propagate in the first place, the user needs to have execution privileges on the system already.
You want to know how else I can turn UAC off? I can break into your home, take your keyboard, and type in the key combination myself.
That’s basically what this amounts to. You’re stuck in the situation where to turn UAC off you need to first bypass UAC and get installed on the machine. That’s why it’s not considered a vulnerability.
The way UAC is more silent in Windows 7 is, it does not prompt for executables that are signed by Microsoft. This means that most of the system components require no elevation at all, since they’re being done by the user at his Computer.
The real protection comes in, when an unknown and unsigned program attempts to run on your machine. That’s when UAC gets all noisy.
The distinction between Windows 7’s UAC and Vista’s UAC is this distinction. Vista’s UAC locked down the machine, even from seemingly harmless tasks (Deleting a shortcut, for example). Windows 7’s UAC is much smarter about it’s protection, and uses digital signatures to be more lenient.
I think the best “solution” I’ve seen is to not allow SendKeys to operate on signed executables. Problem solved, now get to it Microsoft.
Ps:
I’d like to add on, for those who think that this can be compounded with other social engineering malware, that it’s irrelevant.
If one UAC dialog can’t prevent a user from realizing he’s running a dangerous program, then ten UAC dialogs won’t be able to stop him either, so the point is moot.
Edited 2009-01-31 14:10 UTC
This simple technique works on every admin account, and seeing most home users are still admins, this is a very serious security issue.
UAC still prompts for elevation on Administrator accounts.
Try it.
Ah, I see you don’t get what this flaw is about.
The problem is that the in the default setting for Windows 7, changes to Windows’ settings DO NOT trigger UAC – and this INCLUDES the slider for UAC.
In other words, on admin accounts, with Windows 7’s DEFAULT UAC settings, you can maliciously disable UAC without the user ever seeing any prompt whatsoever.
Get it now?
No. For this (the proposed exploit) to even propagate on the system, he’d need to authorize it to run, which would trigger UAC.
That’s the angle from which it’s looked at by Microsoft: It cannot be remotely exploited without social engineering, the user needs to have already run the program (And consented with UAC) before any of this is allowed to happen.
You’re talking about the program already executing on the users machine, which means UAC has one way or the other already been defeated.
Like I said, in cases of social engineering, if the user is gullible, not one UAC dialog, or ten UAC dialogs will be able to stop him from being exploited.
My understanding was:
The user gets a file such as see_girl_naked.vbs The file runs a script that emulates some key strokes and poof no UAC. But you could have a nice new mail server installed
What should happen is a warning see_girl_naked.vbs wishes to modify your system files click yes to allow. Obviously if you say yes your an idiot and very little can save you.
VBScript must be executed within the host environment. Every browser has provisions to protect from script propagation as well.
However, the bigger picture, and point alluded to by many, is that this can be bundled with malware, malware will not run without user elevation, so a lot of the danger is a moot point.
The dangerous possibility was the fact that this could be remotely executed with no privileges what so ever, and be used to disable UAC from outside the computer. This is not the case.
However, the bigger picture, and point alluded to by many, is that this can be bundled with malware, malware will not run without user elevation
Unless the malware starts out by running the script, which is the whole point you seem to be missing. An installer can run this script, which disabled UAC, without a UAC prompt! Then the installer can proceed to do whatever it wants with no UAC prompts, as it has been disabled.
And how do you suppose most malware gets on a user’s machine, through osmosis?
If it promises nude pics of Angelina Jolie, they WILL run it! MS needs to make UAC prompt if there are any changes to its setting under ANY circumstances.
Edited 2009-01-31 16:53 UTC
Point being what? If they were tricked into clicking through UAC one time, then they will surely do it again, if it means the difference between seeing what they think is a naked photo or not.
But whatever, it seems common sense is lost on a lot of people who foam at the mouth and jump at the opportunity to criticize.
Edited 2009-01-31 18:15 UTC
I think you’re missing the point here. If I understand it correctly, the exploit will be able to turn off UAC without UAC ever prompting the user that it is being turned off. So the user will never get the origial prompt that the program/script they just ran is attempting to do something fishy.
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:
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.
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?
Just one little problem with what you’re saying. A script can change these settings… without a prompt. Now, how can a script be run? Well, let’s see here… given how many people seem to illegally download commercial software on the Windows platform, one could simply embed this script in their installer. If the default settings aren’t changed, it will run, no problem. And then everything is open.
So the defaults can be changed. How many average home users do you know who have any idea what UAC actually is, or how to change it? Even if they were told how, how many of them know or care why?
Yes, you’re going to have complainers about UAC regardless of the decisions MS makes. This, however, is a legitimate complaint as it does not require physical interaction to disable UAC. This is a situation where the default security level is insufficient to prevent a script from making changes to the security policy. This is a huge no-no. The fix? Exempt UAC changes from being scripted, forcing a prompt whenever the UAC setting is changed. Leave the other prompts as they are, but always prompt when changing any UAC-related settings. This isn’t too difficult, wouldn’t interfere with the average home user, and those who did want to change the UAC settings would know why they were changing them anyway. Clicking one extra continue button in this one instance wouldn’t hurt them.
Microsoft had better fix this, seriously. If they don’t, they might as well drop security altogether, as they’re leaving the front door wide open anyway.
And how does that installer run? After it’s authorized by the user with UAC.
Voila.
This is the equivalent of saying “I can turn off your house alarm from inside your house”. Well, obviously. Just how are you going to get inside the house? You’re going to trip the alarm somehow in the process of trying to break in.
That’s the simplest terms I can put it in, I hope you can understand.
Look, I think you don’t understand the purpose of UAC. The purpose of UAC is to allow Least User Access to the machine. To allow you to perform everyday computer tasks, without being an everyday administrator. It just so happens that a lot of malware tries to perform administrative actions.
UAC is not a safety net to be used without antimalware / antiviruses, it is just a privilege elevator. People make UAC out to be more than it really is.
It is working as intended, because for the program to be able to execute, one way or the other, you need to elevate your privileges with UAC.
If the user downloads a malicious installer, he’s already been social engineered into running a malicious program, and into consenting with UAC that this program is safe to run.
This is the circular logic I don’t get, how can something which under every circumstance is stopped from executing, be a headline catching critical system flaw? It’s ridiculous and it’s sad that such FUD is spread on this site.
Facts people, they’re good.
Edited 2009-01-31 15:00 UTC
I understand what you say, but are you sure there are no ways to prompt the execution of a VBScript by way of malware installation without prompting the OS that it’s trying to run an unsigned executable?
If anything, the amount of naked_chick.jpg.vbs exploits are surely going to rise.
Either way, even if it doesn’t prompt a full-blown vulnerability by itself, it gives way for a lot of exploits, and always having social engineering on your mind, you can do a lot of things, even trick people into installing things that do not have a “CLICK HERE.exe” installer, but a “CLICK HERE.vbs” installer, which can happily disable UAC and then run all the unsigned binaries it wants. I’ve seen my dad install all kinds of crap on his system this way, regardless of .exe extension.
I don’t think I can start my work PC (Vista) without swearing, I can think of dozens of things that really tick me off – UAC isn’t really one of them although one wonders if some of the warnings are really necessary. If I’m fundamentally changing or potentially fundamentally changing the the software environment / OS I should be warned and permission asked (and I’d say add a password too).
The default described looks poor and if it can be exploited in the way described that looks like a train wreck. Certainly it will be exploited, if it can be and we will have another Trojan / spambot virus infested MS operating system.
Surely they will fix this – I would add if UAC is annoying they could look at removing unnecessary warnings and possibly allow users to suspend UAC for a temporary session (after adding appropriate warnings etc) so that users can configure their systems without being nagged perhaps a button on control panel suspend UAC warnings until control panel is closed?
I see the reasoning by several people here (probably similar reasoning that MS guy used) is basically:
“this is a problem only if you get some malware installed on your system first and to do that you will have to OK an UAC prompt so what good does it do to make the suggested fix here?”
IMHO, if a UAC prompt came up saying “you are trying to change UAC behaviour, please confirm […]” and message came in the UAC prompt only when you tried to modify UAC settings, few users would press OK without thinking twice.
Besides all the answers already given as far as the reasons why this hole must be closed anyways, there are other more subtle ways for this problem to manifest itself… IE, other browsers, other plugins, other OS components, etc… exploits allowing such malicious UAC disabling scripts to be downloaded into your system and started. Something getting through your web browser couldbe quite dangerous too.
I remember when UAC was being introduced in Vista. There were much buzzing about it but I remember MS representatives always stating UAC is not to be considered a security boundary.
They were insisting user is the security boundary level they were taking care of and UAC was only a way to help user to spot potentially dangerous situations. So I guess this is what they mean when they say that behaviour is not a flaw.
Personally, I was against relaxing UAC in Windows7. I find UAC is extremely useful and it helped me spot a couple of bad situations. After all, other systems are imposing user to enter their password to elevate your privileges. UAC doesn’t require you to type password (and I think it’s a right decision) but can be extremely useful. Reducing its impact is not good to me.