Kurt Shintaku's Blog

As I’d mentioned before, I got the chance to talk with Mark Russinovich, Microsoft Technical Fellow and all-around nice-guy Windows-Internals brain.

He’s concerned that people are viewing User Account Control as one monolithic component within Windows Vista… and it’s not.  See, in order to make things simple for everyone to understand, the Windows client team took 4 different security related features & wrapped them all into a single concept called "User Account Control" with the intention of showing how much effort was placed in securing Windows Vista from malware… and then proceeded to market the hell out of it.

The truth is far more complex:  User Account Control consists of 4 separate components:
– System Virtualization
– Administrator Approval Mode
– Rights Elevation
– Integrity Leveling

I’m not going to get into the details of what each of these are except to point out that they are all separate aspects of security designed to accomplish the general goal of security, and the specific goals of:
– Encouraging software developers to write well-written, secured applications
– Minimize the rights applied to a user even when running as an Administrator
– Increase the number of individuals running as standard users instead of Administrators
– Minimize interprocess intrusion & security threats

MARK’S WARNING
"There is no guarantee that malware can’t hijack the elevation process or compromise an elevated application.  Solution?  Switch to a dedicated administrator account for securely running
as administrator."

Basically, what Mark is saying is that it’s not terribly hard for a rogue process that may be running in the context of a standard user, to "invade" or "intrude upon" the resources of another legitimately running process – EVEN IF THAT LEGIT PROCESS IS RUNNING AS ADMINISTRATOR DUE TO RIGHTS ELEVATION.

FOR CONVENIENCE ONLY
For convenience sake, prompted rights elevation (The infamous, "You need to be an administrator to do this.  Please type your Admin username & password now" dialog) was provided within Windows Vista to encourage the usage of standard user accounts and only use Administrative rights when necessary, instead of signing in with them and using them on a day to day basis.

For compatibility reasons however, it was necessary to make interprocess communication easily possible between the elevated process and other processes running in the standard user context. 

The fact is that your Admin account is "susceptible to intrusion" when used to elevate rights while currently logged in using lesser user account.  If

BOTTOM LINE:  ALWAYS LOG OFF
If you’re paranoid, or just don’t trust the end user you’re working with, always log off the user’s account before running administrative tasks using your own admin user account.  It might be possible that the end user got infected with a malware process and that process is waiting for you to use your account to elevate another processes privileges.

For example, if they downloaded something from a "warez" site and ran it, against the policies of your company.  If might appear to do nothing and the end user will just brush it off, when in reality it’s just sitting in the background waiting for Joe Admin to use the computer, elevate their privileges to, say, authorize the installation of a legitimate piece of software, and attack. 

EXAMPLES OF AN INTRUSION TECHNIQUES
One such attack might be to display a phony dialog box on the screen that looks just like the Windows Vista Admin Elevation dialog box when you run anything that requires admin rights.  The phony dialog box might appear over the legitimate one, capture the end user’s username and password, the print, "wrong password – try again", fooling the user into thinking they mistyped something, then show the REAL Admin Elevation dialog box behind it.  The admin would then legitimately log in and never know that his account had just been compromised.

HUMBLE NOTE:
Please bear in mind:  Mark Russinovich is a far frickin’ smarter than I am.  I can barely parse assembly language, shades of my days as a DOS hack, tearing up copy protection techniques with debug as a 13 year old.  Meanwhile, this guy writes in assembly language as a hobby.  So it’s probably better to read stuff straight from the guy’s blog. 

He’s written a blog entry at http://blogs.technet.com/markrussinovich/archive/2007/02/12/638372.aspx that covers this topic and is going through a campaign of sorts to help reeducate the world on how UAC affects people and why administrative rights elevation should be something that is viewed in a cautious light.

He’s also recorded a similar presentation to the one I attended on the topic that’s available online here:
http://www.microsoft.com/emea/itsshowtime/sessionh.aspx?videoid=360