1011491 - [tracking] Tighten Windows GMP sandbox policies

Status: RESOLVED FIXED

(Core :: Security: Process Sandboxing, defect)

Description

[Justin Schuh]

The following appears to be the Windows Sandbox policy
<http://mxr.mozilla.org/mozilla-central/source/security/sandbox/win/src/sandboxbroker/sandboxBroker.cpp#49>:

  mPolicy->SetJobLevel(sandbox::JOB_NONE, 0);
  mPolicy->SetTokenLevel(sandbox::USER_RESTRICTED_SAME_ACCESS,
                         sandbox::USER_RESTRICTED_SAME_ACCESS);
  mPolicy->SetDelayedIntegrityLevel(sandbox::INTEGRITY_LEVEL_LOW);

  // Set an alternate Desktop within a new window station
  mPolicy->SetAlternateDesktop(false);

If that's correct, then this policy won't provide any meaningful sandboxing. The most immediate concern is that it's not using an alternate desktop and it's setting a delayed integrity level. This means that the sandboxed process will run on the interactive desktop without UIPI restrictions. As such, the sandboxed process can launch normally privileged (medium integrity) processes by firing off window messages directly to the shell, to COM handlers, etc.

I'm assuming there's a reason for not using the alternate desktop, but it should be fairly easy to at least enable UIPI. You just need to call SetIntegrityLevel rather than SetDelayedIntegrityLevel, because UIPI is enforced only if you're at low-integrity or below when user32 loads (which happens very early). You might also need to add some IPC glue to have the broker perform any privileged window operations (e.g. cross-process window reparenting). With UIPI enabled the sandbox policy would be comparable to a low-integrity IE content process.

Comment 1

[Andrew McCreight [:mccr8]]

Sidd, do you know who is working on Windows sandboxing now?

Comment 2

[Daniel Veditz [:dveditz]]

I think we're still at the stage of getting Firefox to run in a do-nothing or do-little sandbox at all. Long way to go before we can tighten the screws.

Comment 3

[(No longer employed by Mozilla) Aaron Klotz]

I'd also like to point out that SetAlternateDesktop(false) does indeed enable the alternate desktop; the boolean parameter indicates whether to set an alternate *Window Station* for that desktop. The comment above that line is wrong though and is different what I r+'d in bug 928061.

Comment 4

[(No longer employed by Mozilla) Aaron Klotz]

I do agree with the remarks about UIPI, though: Delayed integrity level dropping works for kernel objects but not for UIPI.

Comment 5

[Justin Schuh]

Yeah, I assumed this was fairly early. I just figured I'd take a look at the policy and see if any input would be helpful.

Also, sorry for my confused comment about SetAlternateDesktop. I clearly lost track of what I was doing and explained part of it completely wrong. Yes, there is an alternate desktop, but the problem is that a bare USER_RESTRICTED_SAME_ACCESS token still has sufficient permission to switch back to the interactive desktop. So, right now the alternate desktop isn't really enforceable. That's why I proposed UIPI as the simplest way to improve that situation.

There's other reasons why you probably want to focus any immediate sandboxing efforts on getting UIPI working. Generally speaking, desktop isolation on its own is pretty weak. E.g. all process on the same winstation share a clipboard, and during certain input handling the shell looks for clipboard content like MoreOlePrivateData and blindly execute the contents as an ActiveX control at medium integrity. Sadly, there's a bunch of other undocumented Windows gotchas like that.

I'm not sure what your plans are regarding XP (since it doesn't support integrity levels), but I should mention that the only enforceable token level on XP is USER_LOCKDOWN. That's because any other token level retains the traversal bypassing right, which allows the sandboxed process to directly open the DACL of any other object from the same owner SID. At that point the escape is to open an unsandboxed process, add some usable SID into the DACL, then reopen the process and create a thread in the target process running at its privilege.

Anyway, hopefully that's useful context and not just pointless rambling. And please ping if you have questions on the or feedback on the Chromium Windows sandbox code. I'm an owner and the primary dev at this point, and it's part of the code that I enjoy mucking around in.

Comment 6

[Sid Stamm [:geekboy or :sstamm]]

(In reply to Andrew McCreight [:mccr8] from comment #1)
> Sidd, do you know who is working on Windows sandboxing now?

Tim Abraldes is working on it (for media plugins first, then we'll use a similar but slightly more relaxed sandbox for content).  Adding him.

Justin: thanks for the info!

Tim: this might be useful info.  Is there any reason to keep this bug hidden given that we are not shipping a content sandbox (it's not finished or enabled yet)?

Comment 7

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

This bug doesn't need to be confidential but I don't have the ability to un-hide it. Someone in the sec group please go ahead and un-hide it.

As mentioned above, we currently put sandboxed content processes in an alternate desktop, but not in an alternate Window Station. We have bug 928055 filed for putting sandboxed content processes in an alternate Window Station. I will likely just include the fix as part of bug 985252.

For the job, token, and integrity levels: Our plan is to start ratcheting down our privileges, fix any breakage, rinse, and repeat. In terms of priority, it sounds like we want to do things in roughly the following order:
  1. Switch from `SetDelayedIntegrityLevel` to `SetIntegrityLevel`
  2. Use a lower job level: It seems like we might be able to get to `JOB_LIMITED_USER` with some effort and ideally we will go even further
  3. Use a lower token: Hopefully we can eventually reach `USER_LOCKDOWN` but I anticipate that this will be difficult

Comment 8

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

Re-assigning to :bobowen so this doesn't get lost as I transition out of sandboxing land.

Bob - feel free to unassign this and/or track however you see fit!

Comment 9

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Move process sandboxing bugs to their new, separate component.

(Sorry for the bugspam; filter on 3c21328c-8cfb-4819-9d88-f6e965067350.)

Comment 10

[Chris Peterson [:cpeterson]]

Bob, is there any more GMP sandboxing work that must be completed for EME on Windows?

Comment 11

[Bob Owen (:bobowen)]

(In reply to Chris Peterson [:cpeterson] from comment #10)
> Bob, is there any more GMP sandboxing work that must be completed for EME on
> Windows?

Not for 32-bit.

Well except for possibly unloading some DLLs on sandbox start-up, but unless someone comes up with the list or I have a working CDM and test suite then that'll have to wait.
As I've said before, my understanding is that it is only a "making life more difficult" measure, not a strict security one.
For Chromium they use the functionality to unload DLLs that they know (or suspect) cause crashes in the renderer. So it seems to be a stability rather than security measure.

We have a process-level mitigation (possibly two) for 64-bit, but it's conditional in the Chromium code, so I haven't had time to work out when it is turned on.

If you want to close down all the dependencies for adobe-eme, feel free to file a new bug just tracking 64-bit process level mitigations or let me know and I'll file it tomorrow.

Comment 12

[Chris Peterson [:cpeterson]]

OK. Win64 support for EME is not part of the Adobe EME MVP, so that work doesn't need to block the adobe-eme meta bug.