Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Security Operating Systems Software Windows

Security Hole In Windows 7 UAC 388

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."
This discussion has been archived. No new comments can be posted.

Security Hole In Windows 7 UAC

Comments Filter:
  • by DavidR1991 ( 1047748 ) on Monday February 02, 2009 @06:10AM (#26692127) Homepage

    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/ [istartedsomething.com]

  • by Anonymous Coward on Monday February 02, 2009 @06:53AM (#26692331)

    if I have a script on my computer that can simulate keypresses and mouse clicks *nothing* will hinder it to click on "I've read the warning"

    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.

  • by amirulbahr ( 1216502 ) on Monday February 02, 2009 @07:01AM (#26692375)
    but is certainly no security expert [istartedsomething.com].
  • by nstlgc ( 945418 ) on Monday February 02, 2009 @07:16AM (#26692439)

    Please, it's not just sudo, it's heap of other crap too. It's "I stopped these things from being launched at startup and there's no way to override this behaviour".

    Your application is trying to be launched at startup in an fishy way. For some reason, my apps are not. HMM.

    It's "I'm silently going to re-route any writes to the C:\Program Files\X directory to a virtual subdirectory under the user account, so that users can see different versions of files when looking in the same place".

    There's no good reason for writing there, and doing so is exactly what messed up "running as an administrator" in XP and below. Ask the author of your application to make it less retarded.

    It's a lot of annoying, unnecessary and unchangeable crap. That's why I switched it off anyway.

    Is it? I've seen many, many ways to reduce or even eliminate the warnings, even without turning of UAC. It's almost like you're being proud of being an idiot.

    YMMV, you may not want an ext2 driver (not MS signed/approved!) launched at system startup, and you may not ever want to edit any configuration files stored in program files (or never launch processes as another user) but I consider those pretty important.

    Yes, I'd prefer that they would install like normal drivers (not at system startup) and that they go through the effort of getting signed. And if you're still on 32bit Windows, this is not even a problem.

    But it kinda confirms my thought that you were running vague software written by Linux people for Windows.

  • by MichaelSmith ( 789609 ) on Monday February 02, 2009 @07:36AM (#26692533) Homepage Journal

    What if the anonymous reader who submitted this was Roland P.? Wouldn't we wanna know that?

    That would certainly be something [slashdot.org].

  • by Anonymous Coward on Monday February 02, 2009 @07:44AM (#26692567)

    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 [wikipedia.org].) 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.

  • by drsmithy ( 35869 ) <drsmithy@nOSPAm.gmail.com> on Monday February 02, 2009 @09:23AM (#26693113)

    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.

  • by magamiako1 ( 1026318 ) on Monday February 02, 2009 @09:23AM (#26693117)
    Viol8:

    UAC mimics much of the functionality present in a lot of Linux applications. You need root to install the application, but you don't need root to launch the application.

    At least, this is exactly how Microsoft has it designed. And anything that requires administrative privileges should have a service that starts as admin/root and then the client side process should be low privileged.

    This is exactly how Microsoft has it setup. The problem is that a lot of application developers are lazy. They don't want to write software for how Microsoft wants it to be written. This has, essentially been how Microsoft has intended software to be written for years. C:\Documents and Settings\User\Application Data has only been around since the Windows 2000 days.

    The aforementioned design, however, has never been enforced by Microsoft.

    And the worst part about it is that users themselves are asking for software to be written poorly. All you have to do is to take a quick look over at the ZSNES forums where the developers openly asked its users how they should store configurations now that UAC gets in the way, and the users tell them "We want it to be more portable!"

    That's fine and all, if you want to install all applications to C:\Users\. But like Linux, there are folder conventions.

    It's all there, everything. The environment for writing secure products that don't get exploited that run within the context of a limited user are all built into the OS already.

    Microsoft even went out of their way to "virtualize" Program Files for applications that fail to follow the proper format.
  • by Jeremy Visser ( 1205626 ) on Monday February 02, 2009 @09:34AM (#26693209) Homepage

    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 [sourceforge.net], 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.

  • by Jurily ( 900488 ) <jurily&gmail,com> on Monday February 02, 2009 @09:50AM (#26693389)

    Unix and Linux are thankfully spared a lot of this.

    *nix has a well thought-out multi-user structure.

    In Windows it was bolted on a basically single-user design originating with DOS. They try to do it right, but they can't break everything when backwards compatibility is all that keeps their empire from falling apart.

    Remember the Windows 98 home directory? Me neither. Noone used it except Microsoft.

  • by Anonymous Coward on Monday February 02, 2009 @10:13AM (#26693667)

    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.

  • by mario_grgic ( 515333 ) on Monday February 02, 2009 @10:24AM (#26693801)

    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.

  • by GooberToo ( 74388 ) on Monday February 02, 2009 @10:46AM (#26694049)

    Uh no. UAC's purpose is to make it possible (in practice) not to use administrator accounts. Pretty much the complete opposite.

    So how is one to use an administrator account without using an administrator account. You've completely missed the boat here. The gp is correct and you are wrong. The point is to allow secure access to administrator accounts without having to actually, explicitly log in as a desktop user as an administrator. So in that sense, you are right, but it does not change the fact the entire point, as the gp stated, it so allowed secure access to administrator accounts.

  • by TyIzaeL ( 1203354 ) on Monday February 02, 2009 @11:13AM (#26694359)
    This doesn't apply to just Windows users. Its referred to as the dancing bunnies problem [codinghorror.com]. It doesn't matter what OS the user is on. If they think they want what the particular malware claims to offer, they'll go through all the administrator prompts you can come up with to get what they want.
  • Re:"Gerald" (Score:3, Informative)

    by MasterOfMagic ( 151058 ) on Monday February 02, 2009 @11:21AM (#26694453) Journal
  • by afidel ( 530433 ) on Monday February 02, 2009 @11:45AM (#26694807)
    Actually the GP was right, your account does not have the admin bits set in the token when using UAC. Responding to the dialog adds those pieces to the token for that app on a temporary basis.
  • by drsmithy ( 35869 ) <drsmithy@nOSPAm.gmail.com> on Monday February 02, 2009 @11:54AM (#26694929)

    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.

  • by plague3106 ( 71849 ) on Monday February 02, 2009 @12:34PM (#26695481)

    Um, that's what they've done. User programs that are causing UAC prompts are built wrong; they're trying to write to \Program Files, and that's been a no-no since Win2k. That's why many programs require Admin access. UAC was SUPPOSED to be annoying so that developers were forced to fix their badly implemented applications. That was the idea anyway, whehter or not it had the intended affect I don't know. Probably not, since people bitch about UAC (and many of these same who run Linux have no problem supplying the root password when they run an X admin tool from a normal user account).

  • by coryking ( 104614 ) * on Monday February 02, 2009 @09:46PM (#26703397) Homepage Journal

    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 /etc/sudoers with 'username = NOPASSWD: [your program]'"
    "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!!

Always draw your curves, then plot your reading.

Working...