Creating an object on the other side of the airtight hatchway isn't yet a security vulnerability


A security vulnerability report came in that went something like this:

UAC can be trivially circumvented as follows.

  1. Sign in as a user who is a member of the Administrators group.
  2. Run Task Manager.
  3. Go to the Processes tab.
  4. Click "Show processes from all users."
  5. Task Manager will relaunch itself elevated without triggering a UAC prompt.
  6. From the File menu, select Run.
  7. Check the box "Create this task with administrator privileges."
  8. Type any program name you wish and click OK.
  9. Observe that the program is launched with elevated privileges and no UAC prompt was ever shown to the user.

The security implications of this are wide-ranging.

Okay, let's see what happened here. You ran Task Manager, then elevated it (by clicking "Show processes from all users"), and then used that elevated Task Manager to launch more elevated processes. So far, nothing is actually wrong. You did manage to launch an elevated process without incurring a UAC prompt, but that's expected because Task Manager is on the list of programs which are allowed to elevate without a prompt. Of course, once you get to Task Manager, you can use that to launch other programs, but that's also to be expected, because that's one of the purposes of Task Manager.

The question then is whether there is a security vulnerability. To do that, we need to answer a few questions.

First, who is the attacker?

The attacker is presumably some malware running un-elevated which is trying to get itself elevated.

Who is the victim?

The victim is the user who has gotten tricked into running Task Manager, elevating it, and running the malware elevated.

But wait a second, is that really a valid victim? If you presuppose a victim who will follow the instructions of malware, then you don't need Task Manager. The malware can tell the victim, "Okay, run this program, and when it asks for permission, say Yes."

Okay, so maybe that's not the victim. Maybe the victim is a user whose account has been compromised by malware (e.g., by exploiting a bug elsewhere in the system), and now the malware is trying to use that as a foothold to auto-elevate itself.

In that scenario, the malware would programmatically launch Task Manager, programmatically click the "Show all processes" button, programmatically open the Run dialog, programmatically check the "Create this task with administrator privileges", programmtically fill in the program name, and programmatically click the OK button.

However, this scenario fails because the malware will be able to get as far as programmtically clicking the "Show all processes", and then all future options will be blocked by User Interface Privilege Isolation (UIPI), which prevents unelevated programs (like the malware) from programmatically driving the UI of elevated programs (like the elevated Task Manager).

In order for the malware to be able programmatically drive the UI of the elevated Task Manager, it must itself already be elevated, in which case it is already on the other side of the airtight hatchway.

Creating an object on the other side of the airtight hatchway is not in and of itself a security vulnerability. You also have to evaluate what you can do with that object. If the object can cause problems by its mere presence, or if you have control over the object and can cause it to create problem, then you have an issue. But if the object's mere existing is not problematic, and you have no control over the object, then you haven't gained anything. You may have annoyed the user (who now has to close that extra copy of Task Manager), but that's about it.

We never did get any details from the finder as to what those "wide-ranging security implications" are. The finder merely said, "This is a trivial UAC bypass."

Comments (26)
  1. The_Assimilator says:

    I'd love to see stats on the total count of security "vulnerabilities" reported to Microsoft vs the number of actual security vulnerabilities. I'm expecting that ratio to be extremely low.

    1. Antonio Rodríguez says:

      You know, Windows is presumed to be buggy and unsecure, where Unix is presumed to be solid and safe. When confronted with a strange or complicated security-related behavior, the default in Windows is to blame Microsoft (even if it involves third party software), where in Unix, it's usual to look for more information.

      1. Karellen says:

        That could be because of the separation in Unix between the POSIX specification and the vendor implementation(s). In order to figure out whether the problem is with your vendor, you need to find the spec and study it to determine what the behaviour ought to be, and why. Only then can you figure out whether:
        a) your vendor has produced a robust implementation of a shoddy API (in which case you're hosed),
        b) your vendor has produced a shoddy implementation of a robust API (in which case you can shout at them to fix it), or
        c) you've misunderstood the API and can now fix your mental model, and your code, without embarrassing yourself in front of your vendor (or on social media) by announcing your mistake.

        Of course, no-one thinks up-front that it might be c), so where the spec and the implementation are by the same people, as with Windows, it probably is very tempting to just go straight to blaming Microsoft.

        Another option is that Windows is thought of as being "easy to understand", whereas Unix systems are known to be subtle and complex - despite Windows' ACLs being more complex (featureful) than Unix' classic user/group/other read/write/execute permissions system. That could mean that people who think they've found a bug in Windows automatically think they've understood things correctly, because Windows is easy to understand. Whereas people who think they've found a bug in Unix are more wary of the fact that there may be subtleties that they're missing.

        1. Kevin says:

          > a) your vendor has produced a robust implementation of a shoddy API (in which case you’re hosed),

          The typical response to that is to invent your own less-shoddy API, get your vendor to implement it (in this case, you often *are* the vendor), and then tell everyone to use that instead, portability be damned. For a classic example of this, Google "completely stupid semantics of System V" (you should see a number of BSD man pages whining about a blatant misfeature in fcntl(2) file locking).

  2. Jan says:

    Also, "there are really only two effectively distinct settings for the UAC slider", and the task manager asks for elevation in the reasonable one.

  3. Joshua says:

    Ah a UIPI topic [now I know the name]. If the suggestion box ever opened again that would have been my request.

    It is interesting to note it is possible to talk about UIPI w/o ever talking about UAC by talking about a service that spawns a process on the desktop deliberately (by stealing the winlogon token for the desired session).

    Incidentally, for domain joined workstations, there is only one effective setting for the UAC slider. \\my-computer-name\c$ works just fine to lay the cuckoo's egg from any other computer on the domain.

    1. Only if that user has permission to access that volume according to the share permissions and ACLs. Even when they do ACLs are still enforced, so a typical user won't be able to write to Program Files or Windows. This isn't the case when you're an administrator, but that's not what UAC is meant to help with.

      1. Joshua says:

        It's just another UAC bypass, and not a fixable one this time. It's not much more of a UAC bypass than a program carrying around its own RDP implementation just a lot simpler.

        1. ErikF says:

          I too can completely bypass UAC if I open up the computer and take out the hard drive (I don't even need an account!) This, however, is not a flaw in UAC because UAC is only designed to prevent certain interactive scenarios, not all possible access methods.

  4. Piotr says:

    is that why drag and drop from windows explorer to an elevated IE doesn't work (but to an unelevated IE works)?

    1. Vulpini says:

      Yup![1] It can get really annoying at times, but there's not much that can be done about it. Except maybe running an elevated (third-party) file explorer, with all the potential security implications.

      [1]: https://blogs.msdn.microsoft.com/patricka/2010/01/28/q-why-doesnt-drag-and-drop-work-when-my-application-is-running-elevated-a-mandatory-integrity-control-and-uipi/

  5. Yukkuri says:

    Sounds like they were assuming the UAC slider was at the max when it was not (or less charitably, don't even know about it)

  6. DWalker07 says:

    Interesting that the article discusses Windows Vista. Are there "too many" articles like this for them all to be updated?

    I wonder if it's difficult to make sure that -- if this is the current documentation for this feature -- this doc should never be erased. Maybe articles like this are NEVER erased.....

    1. voo says:

      "I wonder if it’s difficult to make sure that — if this is the current documentation for this feature — this doc should never be erased"
      Few things are ever erased, but I think we can all agree that that article moved at least once since it was written.
      We're talking about msdn here after all.

      I understand that this is a non trivial problem, but whoever operates msdn is particularly incompetent about keeping URLs working.

      Although the last blog update worked surprisingly well, so maybe things are finally improving.

  7. Ted Spence says:

    One thing I'd be curious about is whether there has been discussion of a "honeypot" or "trap" environment for elevation.

    Given how many programs wish they could run elevated, and how many programs ask for elevation for suspicious reasons, it seems like one approach would be as follows:
    a) Give each application elevation when they ask for it;
    b) Sandbox all of their changes and actions; and
    c) Show those actions to the user to decide whether to approve them.

    The goal would be, when I install a sketchy app that needs to have access to my start menu so that it can add its own startup program, that it goes ahead and does "everything a programmer gets a bonus for doing" - but then I can silently set that aside.

    I know from Raymond's perspective that all feature proposals start with negative-one-hundred points, and this clearly seems extremely complex; but over time the number of sketchy applications that we really wish we could use keeps increasing.

    1. For a typical user, this will just look like noise ("what the heck is this CLSID? Why is it talking about COM objects?"), especially when a program installer installs other dependencies (VC++ runtime, DirectX installers wrt older games, etc.), so they'll just blindly accept and get frustrated in the process. For a power user, it would be useful from an auditing perspective, but even then this list could be absurdly long.

      It also raises other questions: what if the process is long-lived? What if it has external side-effects, like creating firewall rules or network shares? What if it tries to use IPC and expects to have certain permissions that it doesn't? This is kinda why a lot of OSes use "capabilities" instead. Not quite as noisy, easier to implement, and you don't have to worry about side-effects. That being said, a lot of OSes don't let you choose which capabilities to enable and just let you say "Allow All" or "Don't Run", which can be frustrating when you want to run an app but don't want it to have, for example, access to your Documents or to the Internet.

      1. Ted Spence says:

        True - so the big challenge would be "How can this be useful?" I definitely get your point; asking users to approve changes to CLSIDs wouldn't work. So let's think a bit alternatively (of course, since I'm not on the windows team, this is all hypothetical anyway).

        For example, I know if my IPhone came with a virtual-honeypot-contacts list, when an iPhone game asked to use my contacts list I could choose "Allow", "Allow Honeypot", or "Deny". Since some iPhone games refuse to give me certain features if I deny them, I could instead give them my honeypot instead. So maybe the way to approach this would be to only virtualize certain features, like startup programs, that are especially user hostile?

    2. Koro says:

      If they did it, it would just be a matter of time before people found out the exact implementation details and limits of the sandbox, and wrote their programs to "act around it" by being nice for the time they are sandboxed so that they can get allowed for real, then do all kind of nasties once they are really elevated.

      And by the way, this "emulate the program for a bit to see what it does" method is exactly what antiviruses' heuristics module does.

    3. Radosław Cybulski says:

      As other fellows already responded its rather hard to make your idea work. But why exactly do you need to present those changes to the user at all? You can just keep them and reinstance sandbox every time the application is launched. This could consume some more memory (and hard drive), but it could be manageable. As a bonus, once you would uninstall an application, you would remove the sandbox with it, thus removing any traces of the application.

  8. nic says:

    Sign in as a user who is a member of the Administrators group.

    Has a security vulnerability that starts with this ever being an actual vulnerability.

    1. my123 says:

      Yes, for example a Code Integrity bypass for loading unsigned drivers, or a Secure Boot exploit.

  9. Tor says:

    I think many people are confused about what UAC prompts are for. On Linux you have to type your password when using sudo to do something as root. You can exempt certain commands, and it would be a security issue if one of them allowed you to run arbitrary commands as root.

    UAC prompts are similar to sudo in some ways, but not the same. They are only there to limit programs acting as the user, not the user themselves.

    1. Except that the user is also limited when UAC is enabled, since they have less privileges applied to their token than a standard administrator. UAC works a lot like sudo, but with less control (and sudo is essentially running a process as root but inheriting your environment, while UAC is running as you but with all the privilege flags enabled).

      It still bothers me to no end that there's no way to force Windows to allow non-elevated users to create symlinks, at least with a group policy.

      1. smf says:

        Yeah that is weird, and not being able to delete a symbolic link to a directory that contains open files is odd too.

  10. Raymond you forgot to point out that whomever reported this also used the admin account as their regular account; because if their regular account was a normal privilege account (which every one should do) then task manager/UAC would show a administrative password prompt.

  11. MarcK4096 says:

    "The malware can tell the victim, "Okay, run this program, and when it asks for permission, say Yes.""

    Sadly, this works because users have been conditioned to following instructions like this in order to get poorly written legitimate software working. Our users were once told by a big payroll company to uninstall the latest version of Java and install an ancient version in order to be able to get into the system.

Comments are closed.

Skip to main content