Geeks With Blogs
Running with Code Like scissors, only more dangerous

The Windows Vista UAC exploit I recently published has garnered some attention as well as some criticism.  I wanted to take a moment to reply to some of what I've seen in the press, in comments around the web, as well as the response from Microsoft.

On some of the PC World/PC Magazine and their affiliates' web sites, there was a comment that "Pac-Man" should never require elevation (I use a Pac-Man clone as an example of what would otherwise be innocuous software in the whitepaper).  This is true, and in fact, the clone never does require elevation.  Neither does the photo gallery application you just opened from your e-mail.  Without requiring elevation -- running as a standard user -- the first stage of infection is completed: your Start Menu and Desktop and Quick Launch shortcuts have been redirected and stub executables have been generated.  Malicious code isn't necessarily owning your computer at this point - it most certainly may be "owning" you, but since it's just you, and not any other users, you're probably okay.  Now, this malicious code may sit there for weeks or months before it's activated.  But maybe there's going to be that one day that Warcraft needs to be patched, so you need to run it as an administrator.  So, using your Start Menu, you right-click Run As... and now, Warcraft starts, but so does the malicious program (in the background, of course) - so you don't know it, but your entire machine is now at risk.

Running as a Standard User - one of the primary design goals of UAC, as told by Microsoft - does not and should not prevent reads to other parts of the system, so if you're running as a standard user, you're most definitely subject to data mining if you run an untrusted application.  But that's been true since Windows 95 and probably even further back, with the exception that there wasn't really much of an internet during the days of Windows 3.x.

However, one of my main criticisms of Vista - and this has been true since the UAC dialogs were first presented - was that it instructs users (via classical conditioning) to simply accept any dialog box.  I know Microsoft employs some number of psychologists to help work with focus groups and usability studies.  I'm not sure where they dropped the ball, but this really is psych 101 stuff.  "I want to run this program.  It asks me if I want to go on or cancel.....  Cancel, it must be bad.  Wait!  My program didn't come up.  (Punishment).  I'll try again....  I'll give it approval this time.  Ah, there's my program!  (Reinforcement)."

As a Microsoft technologies developer, and someone who really respects what they've done for the industry, it isn't particularly fun for me to be critical of them.  I remember thinking of Microsoft as the potential highlight of a career in development when I was a freshman getting my feet wet at the job fairs on campus.  Honestly, I still do - so many smart people work there, and there are so many cutting-edge tools being developed, not to mention the research (Singularity?  Who wouldn't want to see a managed OS?) being conducted.  But let's be honest: aside from stuff they just downloaded, how often are users going to need to have a Start Menu or Desktop shortcut pointing to something in their user folder?  Or, how often are there going to be duplicate shortcuts from an installer in the All Users *and* the specific user's folder?  I think in all of my time since the Win9x years, I can count on a single hand the number of times that there have been duplicates.

I think that this points not to a major flaw in the operating system's security features -- indeed, Vista is very much a hardened OS, and I think that social engineering attacks are going to become more standard (as opposed to hacks such as buffer overruns) in the next five years -- but rather a design flaw in the implementation of the user interface.  Who decided that it was a good idea for a user's shortcuts to shadow the global shortcuts (on the Start Menu) -- why aren't there duplicates?  And on that note, why don't we just display both?

There are other, deeper design issues that bug me, less from a security standpoint but more from a development standpoint.  For instance, in both Win32 and .NET, security objects are provided on a per-thread basis.  Why isn't there some way for me to programmatically, in C#, to do something like so: 

   1:  IPrincipal stdPrincipal = Thread.CurrentThread.CurrentPrincipal;
   2:  IPrincipal principal = null;
   3:  if (Microsoft.Win32.Uac.TryAcquireElevatedSecurityToken(out principal))
   4:  {
   5:      Thread.CurrentThread.CurrentPrincipal = principal;
   6:      // now we have admin access for whatever we need to do.
   8:      Thread.CurrentThread.CurrentPrincipal = stdPrincipal;
   9:  }

In older systems, TryAcquireElevatedSecurityToken should return the current Principal if the user already has the administrative role, or null if not.  On Vista, the UAC dialog would appear: a confirmation-only dialog if the user is an Administrator running in Admin Approval Mode, or a Provide Credentials dialog if the user is not an Administrator.  Sadly, this API does not exist.

This code, of course, requires the security policy of the machine to allow this code the appropriate SecurityPermission.  I suppose the design argument around preventing something like this was that it was available through COM and that allowing too much of an attack surface would cause problems - but isn't that really the developer's responsibility, not Microsoft's?  Developing a self-contained, plugin-based, automatically-updating application has become instantly much harder, because I need to inform the user that he/she needs to restart my application with Administrator privileges to do any of that plugin installation or updating garbage.  That's not right - the user would have to start the app a total of three times before being able to use the program securely.

Likely, another issue is that the elevation by UAC requires a change (by default) to the secure desktop - this could cause marshalling difficulty to the standard process.  I'm not entirely certain. 

All told, I'm a big fan of Vista -- I've been using it since its release to MSDN subscribers in November.  I'm very impressed with the hardening they've done, particularly in the implementation of ASLR (Address Space Layout Randomization) and the stack checks present in both .NET and the standard CRT.  And I definitely run with UAC enabled.  I just think that UAC is teaching the average user to constantly click "continue," and particularly for home users this could be a disaster.

Posted on Saturday, May 26, 2007 2:13 AM | Back to top

Comments on this post: Some follow-ups to the UAC exploit

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Robert Paveza | Powered by: