Security Hole In Windows 7 UAC
An anonymous reader writes "A prolific blogger is warning of a possible security hole in the latest beta version of Windows 7. Long Zheng has posted both a description and a proof of concept for an issue that could allow an attacker to skirt the User Account Control component in the new version of Windows. The problem, explains Zheng, is that UAC itself is controlled through system settings. This can allow an attacker to completely disable the protections without user notification. Zheng notes that the issue can be easily fixed by changing the UAC setting to notify users when Windows settings are altered, and that Microsoft could remedy the problem by prompting the user when the UAC setting is altered."
MS have already said that this flaw is "by design" to stop the appearance of too many UAC prompts when users alter their own system settings
http://www.istartedsomething.com/20090131/microsoft-dismisses-windows-7-uac-security-flaw-insists-by-design/
That's completely wrong. The entire point of the UAC prompt is that it can't be automatically dismissed by simulated user input. The UAC prompt runs on a separate virtual desktop from everything else (which is why it flickers), and the kernel enforces that only real user input can touch it, and you can't run your own code in the kernel without going through a UAC prompt, so it's secure.
If this guy is right and UAC can be disabled without user input, then the entire UAC system instantly becomes pointless. Saying that you shouldn't be running as administrator is stupid; UAC's purpose was to make it safe to use administrator accounts. If you can't do that, then UAC has failed. Anyway, Administrator accounts are the default and therefore what 99% of users are going to be using.
but is certainly no security expert.
What if the anonymous reader who submitted this was Roland P.? Wouldn't we wanna know that?
That would certainly be something.
http://michaelsmith.id.au
I'm afraid you're wrong. When UAC is on programs you execute are run under your user account which is normally (by default) a member of the Administrators group. However, the programs are run in a special mode where they are prevented from actually using most of the administrative rights granted to your account. (You can read all about it in Wikipedia.) When a UAC prompt comes up you don't have to type a password because you're not logging in to a different account; you're just granting permission to use the full administrative rights your account already has.
It is also possible to use UAC from a non-administrator account. In this mode you must type a password every time a UAC prompt comes up, instead of just clicking "continue". Few people do this because it is not the default setup and it's even more annoying than regular UAC.
No it doesn't. If you install Vista with all the defaults then you are a member of the Administrators group. You still have to go out of your way if you want to start out with a plain old unprivileged user.
"Administrator" in Vista is not the same as "Administrator" in earlier versions. It is akin to be being an 'admin' in OS X or Ubuntu - it just means you can elevate your privileges if required, not that you can do whatever you please.
You mean apart from the inability of your script to interact with the separate Desktop that UAC prompts occur on ?
Right on the money.
I use Synergy 2, which lets me control my keyboard and mouse from another computer over the network. It's functionally no different to a keypress simulator like the G.P. mentioned.
When using Synergy, I cannot use the remote mouse and keyboard to accept UAC prompts. I have to move to the local machine and physically click the button locally for it to work. Same goes for administrative apps -- if an app is running with administrative privileges, Synergy cannot register clicks on the privileged window. Unless I run Synergy itself as an administrator.
The short answer: Because you're not really running as an admin. On OS X, the "admin" accounts are not really admins. They are allowed to authenticate to use root privileges however. To put it simplified... for *nix, regular user accounts are a member of the "users" group. If you decided that user account should have access to the sudo command, you add them to the "wheel" group (at least that's how it's setup on my distro).
Now, let's compare to Windows Vista/Windows 7: Your "regular" user account is actually a member of the administrators group. The application in question is asking permission to use your full administrative permissions. You are not inputting a password to authenticate higher privileges. You already have them, you just saying "sure, go ahead" to the application/installer/whathaveyou.
Well it's not that simple. On OS X for example you can be an administrator and you still can't delete system files. You need to be root to do that. Also, in OS X you can not create "root account", and login into your session as root. It is simply not allowed and impossible to do. On Linux you can.
So for that hypothetical admin user to delete everything he would have to first become root (either by doing sudo, or starting a root shell, being authenticated first) and then executing rm -rf /
So, to recap, being an Administrator and just executing rm -rf / will not delete system files.
As the island of our knowledge grows, so does the shore of our ignorance.
Also, in OS X you can not create "root account", and login into your session as root. It is simply not allowed and impossible to do.
sudo su -
Congratulations, you're logged in as root.
sudo passwd
Even more congratulations are due, you now have the ability to login from the login window as root.
So, to recap, being an Administrator and just executing rm -rf / will not delete system files.
Actually, on an OS X system there are (or were, I haven't looked for a while) a lot of system-level files (including a lot of stuff in /Applications, like Installer.app) that are writable by any 'admin' user. So even without elevating, an 'admin' user could do a lot of damage to an OS X machine.
That is 100% not true. Your user account *is running as a regular user* no matter what group it is in. It doesn't matter if you are in the admin group (unless you stupidly disable UAC, in which case you basically run as root).
"UAC" = "sudo [program name]"
"Vista, Administrator Group" = "your account is in
"Vista, non admin group" = "sudo [program name] with password, but that depends on the group policy... "
Your highly moderated post is 100% mis-information and is *not true*. YOU ARE NOT RUNNING AS ROOT UNTIL YOU ELEVATE VIA UAC!!