At OSNews, we usually do not report on individual security breaches, because there are websites specifically tailored to that sort of thing. Still, every now and then, an interesting security issue pops up that deserves some attention. How about this one: through a simple VBScript, you can completely disable UAC in Windows 7. The reason for this might surprise you. Update: Microsoft’s response.
When Windows Vista was first released, it came with User Account Control, and right about that time, the world ended in flames and we were all doomed, we died, and that was it. At least, that’s how some described the advent of UAC. Others saw it as a necessary evil to fix developers’ attitudes towards writing applications for Windows, an attitude fostered by Microsoft’s own inadequacy; it succeeded wonderfully at that. The number of prompts lessened anyway after first setting up your machine.
Sadly, when it came to developing Windows 7’s UAC, Microsoft decided to listen to the hissy fit group, and they implemented a slider control where you could set which events would trigger a User Account Control prompt. A classic case of sacrificing security for the sake of perceived usability, if you ask me.
In any case, the default setting in Windows 7 is “Notify me only when programs try to make changes to my computer” and “Don’t notify me when I make changes to Windows settings”. That second one is the root of the very simple security breach described by Long Zheng (of IStartedSomething) and Rafael Rivera (of WithinWindows.com). Since changing a Windows setting does not trigger UAC – changing UAC settings does not trigger UAC. In other words, you can completely disable UAC without the user ever having to give any consent. Put a few keyboard shortcuts in a little VBScript, and there you have it, UAC disabled completely (proof of concept).
Funnily enough, there is a very easy fix for this flaw: enable to the full-blown, Vista-esque UAC in Windows 7 (move the slider all the way up). This setting makes sure that if anyone tries to change you UAC settings, you’d see a UAC dialog. As Zheng accurately remarks, “Having UAC on at the policy as it is currently implemented in Windows 7 is as good as not having it on at all.”
While this exposes the boneheaded implementation of UAC’s settings slider in Windows 7, it also has its roots in sacrificing security for usability’s sake. Let this be a lesson for you: it’s simply not wise to disable UAC, or cripple it just because you don’t like dialogs. I always run my Windows Vista and Windows 7 machines with the full-blown UAC for this very reason.
I personally don’t mind when you guys post security-related stuff on here, especially if it’s particularly nasty. And this one seems to be one of those
Even if it’s aimed at a product still in beta.
“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.”
What if I’m not running as an Admin account? Because that’s always what I do, whether on Leopard or Vista.
Microsoft just doesn’t get it and apparently never will. The reason why this is dangerous is because most people run as Admin. Why? Well because its the default Microsoft account and because they never pushed their “developers developers developers” to write their software to only need user level permissions. This is the same thing as allowing your email program to execute code from emails. Who in their right mind thinks that is a good idea or a useful feature. And that is responsible for most of the viruses that propagate by email. Microsoft needs to be put down like the rabid dog it is.
There’s nothing wrong with using an admin account in Vista, that’s one of the goals of UAC.
I might be wrong, but the problem seems to be than in 7 changing UAC level does not cause an UAC prompt. I don’t know why this couldn’t be fixed by MS by simply forcing an UAC prompt in this particular case while keeping it as it is in the rest of them, thus staying less annoying that it is in Vista now.
There is EVERYTHING wrong with running as Admin. It is a better security design to run with the least privileges possible and have UAC elevate them only as needed. UAC gets shut down, then the end result is your user can’t get admin and you have to fix it. As it is now, no UAC, full admin access by whatever you run.
Edited 2009-01-30 23:54 UTC
Unfortunately what we see now is a by-product of Microsoft’s own business model – perpetual backwards compatibility and all the crap that ensues from it. When you make unrealistic promises to your customers, you are going to find that in the future that it limits what you can and can’t do with your product.
What Microsoft needs to do first and foremost is plant a stake in the sad and say, “from this day forward – we’re going to pull all the backwards compatibility out of the operating system, we’re going to enforce proper security so that there are no longer nasty hacks like UAC. All backwards compatibility will be provided through a virtualisation session”, then leave it at that.
The moment when Microsoft puts correctness above rushing a product to market, maintaining compatibility for ‘Joey Spit Waters’ for his 20 year old DOS application, will be the day when you’ll see Windows make a giant leap forward and make the changes engineers in Microsoft have always wanted to make but due to this stupid doctrine of perpetual backwards compatibility, there has been limits in what they can do to improve the operating system over all.
Err… that is precisely what UAC does when you’re running as admin. What do you think the UAC prompt is for?
UAC is for elevating processes or applications up from a user account, to a level needed to run under administrator privileges.
Much like SUDO under Linux.
Inaccurate. Once again: admin accounts in Vista do not run with elevated privileges until an UAC prompt has been accepted. In Vista it does not matter if you are using an admin account or not, you’re getting an UAC prompt anyway. The only difference is that if you are using a standard user account, you have to enter an admin’s password and can’t get away with only clicking the OK button.
2 years later and people still can’t get it?
Edited 2009-01-31 18:19 UTC
If that were true, then when UAC is shut off, you would no longer have Admin rights. But that isn’t the case if you are running as the administrator. They need to model this like Linux. I run as a normal user, not root. But if I need root privileges, I get a password prompt to start the application.
EDIT: to clarify, the difference is in what the user account type is normally. In Windows, you run as Admin and UAC, if its running, prompts you when you do something that requires admin rights. Problem is, no UAC, no prompting, you can do everything as an Admin. On Linux, you run as a user, and get prompted when you need Admin rights. On linux, no prompt, and you get no Admin rights. Its just a safer route to the same goal.
Edited 2009-01-31 17:56 UTC
Personally, I like what Mac OS X does–it uses Sudo underneath, but ads a bit on top of it. If you’re running under an admin account, you get prompted for your password. If you’re running under a non-admin account, you get prompted for an admin account and the password associated with that account.
I’m not so sure about the default settings in distros like Ubuntu. It seems to me that entering my own password to perform administrative tasks isn’t very secure, if the idea is to have the account restricted. If someone did hack in under that account, the entire system would be open to them as they would have already obtained my password. Further, the password is cached. So, if I use an admin program, walk away, and someone else quickly uses my computer, they are elevated without needing to know my password. They would not be able to do this if they were able to get into my restricted account on my Macbook–and further, even having physical access to the keyboard wouldn’t allow them to elevate even if they new my account password. My admin account name is not obvious, and my admin password is not even remotely related to my restricted account’s password. Further, the OS X GUI doesn’t cache my admin credentials. Other distros, such as OpenSUSE, demand the root password for administrative tasks, which also makes sense. I just don’t see how Ubuntu’s defaults are secure in any way, and I see a lot of people here touting them as being the right way to go, which I cannot understand.
Edit: I’m referring, above, to the administration commands that are executed via sudo in Ubuntu. There are other commands, such as the user/groups and services manager, that require you to unlock them with both an admin username and password, similar to OS X’s system preference pains. This unlock approach makes sense to me from a security standpoint, whereas the sudo approach does not.
Edited 2009-01-31 22:55 UTC
From my understanding the sudo command is basically the good old “su” on steroid.
So instead of doing
$su
#sys-config
#exit
you would just do
$sudo sys-config
Makes perfect sense to me.
I guess it’s a simple matter of locking the account whenever you leave your console unattended. While you’re leaving your Mac book unattended, I could, say, set up a malicious program, rename it to “ls”, change your $PATH too so that next time you ls with admin privilege it’ll spoil your day.
Not entirely. It *can* be configured that way, running any program as root if you provide the right password. But it can also provide more fine-grained security which ‘su’ cannot.
With ‘su’, to allow a user to run one command as another user, you would have to give them that user’s password, allowing them to run *any* command as that user.
With ‘sudo’, you can authorise one specific user to run a specific command as another specific user – using their own password to identify themselves, not that of the target user.
That said, be *very* careful when configuring sudo in this way. If you want to be secure, you need to think through all the ways someone could use the privileges they’re given to get more. For example, if you’re letting them run a specific shell script as root, set and export the PATH at the top of the script – otherwise the user can use their own PATH to make commands behave differently than intended (e.g ‘cp’ is actually /tmp/cp, which is actually a symlink to /bin/bash – instant root shell).
No, you couldn’t. Because, as I run in a restricted account, I cannot sudo to admin from that account. I must first su to my admin account, then sudo if I need to use a root command, and as I always su with the – parameter that would block your little tactic.
To be clear, I don’t have a problem with sudo. I have a problem with its default configuration in some distros.
Huh? If you can su, then why even bother sudo after that?
Because I keep the root account disabled, maybe? An administrative user in OS X doesn’t have root privileges. Basically, it gives you the ability to sudo, as well as easy access to ffolders such as /Applications (i.e. you can modify these folders without a password). Basically, the su is just an added layer of security. If you get past the su, however, there’s nothing to stop you from sudoing. At least it would require you to be able to obtain two passwords rather than one, as well as needing to find which user or users have admin rights. Foolproof? No, but no security measure is. But its enough to stop the script kiddies out there.
I like what Mac OS X does as well – it silently gives anyone root access if you type in a short Applescript command (no prompting) and when you move files from one disk to another, it deletes the source file before the destination file is complete.
Took Apple 4 years to fix the first one, and they had the attitude of “smart people don’t use the ‘move’ function” that is similar to how Microsoft is reacting.
Last I checked, Mac OS X’s default account level is admin as well. Does Apple “just doesn’t get it” either? Or is it you that doesn’t get it? Let’s see, two billion-dollar companies vs one random poster on a message board? I’d wager the former put more thought into this than the latter.
BTW, in Vista processes launched from neither “admin” nor “standard” accounts have actual “admin” privileges without going through UAC to elevate the privileges. The only difference between “admin” and “standard” accounts is that the latter’s UAC prompts require a password. Your rant indicates that you think that the processes launched via “admin” accounts in Vista have actual admin privileges without going through UAC. That’s not the case.
For Windows 7, my understanding is that this behavior’s been modified such that apps that come with the system and are signed by Microsoft can elevate privileges without going through UAC. I think this is stupid. Microsoft caved into the howls of those claiming that they ran into UAC prompts every 2 minutes; these claims were shameless hyperbole meant to badmouth Vista, and it even got to the point that Apple had ads lying about how often UAC prompts came up. I think Microsoft should’ve left UAC as it is in Vista. The “power users” that change the system’s settings every 15 minutes already know how to disable and then re-enable UAC, so what’s the point of changing the behavior other than pandering to the likes of Dvorak?
Seems that one sign of end of times is fading.
First we herd that Windows 7 would come in hordes of different versions and now that it might have sucking security.
Now it just needs to get Intel core i7 to its knees and eternal recurrence of Windows is complete.
This is the reason that people release betas, so the community can respond. This particular thing is very easily fixed, just make changing UAC settings something you always prompt for.
But while the fix is simple, will Microsoft have the brains to fix it before shipping out it’s release version? The original UAC in Vista does not seem to indicate that they listened that well to the beta testers then.
Yes, beta testing is good, but it is no good if you don’t pay attention to the testers.
Hi,
If Microsoft weren’t smart enough to realize this problem existed when they were writing the code, then how many other security holes do you think there are that beta testers haven’t found yet?
– Brendan
that’s my feeling. Now where everyone has at least 2 GB + Dual-CPU, plus all the fixes added, it is actually ok. Better than jumping into the next experiment at.
Maybe where you live, but in the rest of the world, that is classed as a major PC.
I’ve used Linux, Mac OS X and various Linux distros and the reason UAC sucks is because it frequently offers more than one dialog and blanks the screen so that it can give you that darkened effect for one of them, and the machine hangs during the process, sometimes for several seconds. Of course, to do admin jobs on Unix you need a password, but I have never found that half as annoying as Vista’s UAC because it’s better implemented and it only asks you once per job.
Run with Software Restriction Polices for Windows and SELinux for Linux if you care about security! Everything else is bloggers to chat about!
It is a real pain to configure SELinux but SRS for Windows XP or Vista/Win7 is easy to setup. A virus can’t even execute on my box.