Slashdot Mirror
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.
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.
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.
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!!