Digital Mind-Reading: How NOT To Handle Reduced-Privilege Environments

Current approaches to reducing privilege in the desktop world take the technically wrong-headed approach of creating user accounts with huge levels of privilege, and then simultaneously using these accounts to run tasks with limited privilege. The line isn’t at all clear. This effectively forces your computer to become a mind-reader everytime you log on. Suffice it to say, the accuracy is none too impressive…

What did impress me was reading about Michael Howard’s DropMyRights tool for Windows XP. After I put the tool to the test, however, my enthusiasm fell considerably. Howard’s DropMyRights tool suffers from one unavoidable issue: an OS that was never meant to be used in the fashion Howard intended.

In all fairness, Michael Howard is no fool. As a Microsoft Security PM, Howard has been one of the most outspoken voices on secure coding for the Windows platform. He still recommends (and in no uncertain terms) the tried-and-true (however painful) advice of running as a limited user. I, for one, am following it. I was more interested in the seemingly bizarre premise of Howard’s tool: the ability to reduce the privileges of arbitrary applications from an administrative context to a limited user context.

I also found related tools, such as the RunAsAdmin project, which appear to be a first effort of sorts at implementing the type of protection offered by the User Account Protection (UAP) feature of the forthcoming Windows Vista. The RunAsAdmin tool is a “shim” around the infamous explorer.exe that causes the shell to be run with Normal User (or less) privileges, even when the user who logs on is an Administrator or Power User. Such powerful users need to use a taskbar icon to run fully-privileged tasks.

After reviewing and deploying both tools, I attempted certain actions that would be permissible for an administrator, but not a normal user. These include privilege uses, registry alterations, and file system modifications. All were denied as expected. It would appear on first-glance that I had indeed managed to surrender all of my extra access and privileges, and was no longer a danger to my system. It would also appear that the project team for RunAsAdmin has given us an eerie glimpse of a sort of “unpolished UAP”. If that is the case, we can only hope that Vista’s final implementation isn’t as dangerous to security.

Why the sudden change of tune, you ask? As I marveled at this unique paradox (an unprivileged privileged user), a thought occurred to me:

“How does such a user authenticate themselves to other systems or services in such a limited way?”

Armed with little more than excess free time, I set to work on the question at hand. It didn’t take me very long to figure out my answer.

I had three theories about how this process could take place, or not take place:

1) Any application run as a user with this kind of arbitrary limitation loses the ability to automatically gain access to such services, and is forced to either:

a) use a null session
b) prompt the user for legitimate credentials

2) Any application run as a user that has been limited will pass on its full token context (as opposed to purely its logon credentials), and thus the full extent of its limits, to the remote service.

3) Any application run as a user that has been limited simply uses the original username and password of that user to any services requesting authentication.

Can you guess which one actually happens? Here’s a hint: why am I writing this article?

You guessed it… it’s #3. If a process run by me submits a request to a remote process to do a task on my behalf, it uses my username and password to authenticate to that process, and that task then inherits the original, unchecked, full power of my account… whether the original requestor is limited or otherwise.

To see for yourself, use Howard’s “DropMyRights” tool from an administrative account to spawn a process like Internet Explorer, that has easy access to files. Go to your system root directory (C:\WINDOWS, usually), and attempt to move, delete, etc., some system file there. You’ll be denied.

Now, access the same directory via the network redirector, using Windows XP’s built-in, immutable administrative shares:

\\127.0.0.1\C$\WINDOWS

Move a file from that directory into some subdirectory of it, and then watch the file disappear. If you moved a system file, a refresh will even show you that Windows File Protection (WFP) has restored it to its original location. Congratulations, you’re authenticated to your own system (silently, no less) as a full administrator from a limited process.

Had malware done the same thing, it wouldn’t present you a pretty graphical shell, and you can bet it would do far more damage than moving a file or two out of your install directory.

This disaster of a privilege-limitation attempt illustrates just how wrong-headed the entire design is. It’s wrong on two points.

First, you never start with excess power and then try to rid yourself of it. You always build up power as you need it. To do it the other way around is to invite laziness and error, and expose your entire network to more danger.

Second, people forget that what is signified by a username/password combination is an authority, not an identity. People try to make accounts serve as identities, when they are nowhere close. The strength of the identity is directly proportional to both the strength and the secrecy of the password. If either is compromised (and in a lot of cases, one of the two is severely so), identity is worthless. Further, even the strongest, most well-guarded passwords provide only a questionable level of identity verification.

Regardless of how vulnerable the identifying intent behind passwords is, though, your use of a username and password is a claim to the authority to use any rights tied to the account you’re accessing. In the case of an administrator, that’s essentially the right to destroy your PC if you so choose. Attempting to limit rights in this context is roughly equivalent to giving the applications you run this excessive amount of power and then trying to prevent them from using the powers you’ve been afforded.

I suspect that this is why you won’t find the three privilege-limiting software restriction policy options (which are used by Howard’s tool) listed in XP’s Local Security Policy snap-in:

  • Normal User
  • Constrained
  • Untrusted

Instead, all that’s available to you is “Unrestricted” and “Disallowed”. It’s no wonder, now… why that is. The design is so fundamentally flawed as to make its entire premise of securing your system utterly false. When the same set of credentials that made you a serf can make you a god, you force your computers to become mind readers. Odds are, they’ll get it wrong. That’s bad news for your security.

Will we see the same thing in Vista? Who’s to say. But, unless Microsoft delivers on the redesign it promises, there’s a good chance that running with privilege, protected or otherwise, will be just as dangerous as it always has been.

Share
  • Roland Dobbins

    Good stuff . . . but, please publish full feeds, not just excerpts.

    Thanks!

  • Toby Murray

    Have you checked out Polaris, from HP’s Virus Safe Computing Lab?

  • Pingback: Dinis Cruz @ Owasp .Net Project

  • Yuhong Bao

    Fortunately, this attack cannot target a computer that has Windows file sharing disabled. And the logged on account themselves must have permission to perform the operation. And to target a computer other than the local computer, the computer’s name must be known.

  • Pingback: Sash Windows