Investigate if we can block loading random DLLs into our address space like Edge is doing now

NEW
Unassigned

Status

()

defect
4 years ago
2 years ago

People

(Reporter: Ehsan, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

()

Reporter

Description

4 years ago
This blog post explains a new kernel feature on Windows which lets Edge prevent random DLLs being injected into their address space.  This could be a huge security/stability win but unfortunately the blog post doesn't contain any information about the feature in question and whether it's open to non-Microsoft apps.

<https://blogs.windows.com/msedgedev/2015/11/17/microsoft-edge-module-code-integrity/>

It would be nice to investigate this.
I thought I saw someone from chrome team say on twitter it was locked to MS DLLs.  I can't find the reference right now, though.
I agree, this might be useful to us depending on its implementation details.
I asked Crispin Cowan from Microsoft how they do this and he said they use SetProcessMitigationPolicy (https://msdn.microsoft.com/en-us/library/windows/desktop/hh769088%28v=vs.85%29.aspx)
Reporter

Comment 4

4 years ago
Looks like we have code that calls this in the tree coming from the Chromium sandbox, but AFAICT neither us or Chromium use the MITIGATION_EXTENSION_DLL_DISABLE flag.  At least in theory we should be able to test this by turning on that flag...

Bob, do you happen to know anything about this?
Flags: needinfo?(bobowen.code)
(In reply to :Ehsan Akhgari from comment #4)
> Looks like we have code that calls this in the tree coming from the Chromium
> sandbox, but AFAICT neither us or Chromium use the
> MITIGATION_EXTENSION_DLL_DISABLE flag.  At least in theory we should be able
> to test this by turning on that flag...
> 
> Bob, do you happen to know anything about this?

Assuming that they are using ProcessExtensionPointDisablePolicy with SetProcessMitigationPolicy, then yes we could.

As I understand it the sandbox uses UpdateProcThreadAttribute [1] with PROC_THREAD_ATTRIBUTE_MITIGATION_POLICY to set most of these mitigations on process startup, but it looks like they are set again when the sandbox is lowered, using SetProcessMitigationPolicy.
I think this is because some can't be set at start-up for some reason

It's not quite clear to me that the disable extension points mitigations is the same as what is being talked about in that article.

[1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms686880%28v=vs.85%29.aspx
Flags: needinfo?(bobowen.code)
Here's a try push with that mitigation enabled for all three child sandboxes:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=5ca00b18b3cb

For NPAPI you'll either have to set dom.ipc.plugins.sandbox-level.flash=2 or run 64-bit.

Everything seemed OK from some very brief browsing.
(In reply to Bob Owen (:bobowen) from comment #6)
> Here's a try push with that mitigation enabled for all three child sandboxes:
> https://treeherder.mozilla.org/#/jobs?repo=try&revision=5ca00b18b3cb
> 
> For NPAPI you'll either have to set dom.ipc.plugins.sandbox-level.flash=2 or
> run 64-bit.
> 
> Everything seemed OK from some very brief browsing.

Just realised this is only Win8+ and I'm running Win7 on this machine, so it's not surprising that I saw no problems. :-)
Reporter

Comment 8

4 years ago
(In reply to Bob Owen (:bobowen) from comment #7)
> (In reply to Bob Owen (:bobowen) from comment #6)
> > Here's a try push with that mitigation enabled for all three child sandboxes:
> > https://treeherder.mozilla.org/#/jobs?repo=try&revision=5ca00b18b3cb
> > 
> > For NPAPI you'll either have to set dom.ipc.plugins.sandbox-level.flash=2 or
> > run 64-bit.
> > 
> > Everything seemed OK from some very brief browsing.
> 
> Just realised this is only Win8+ and I'm running Win7 on this machine, so
> it's not surprising that I saw no problems. :-)

Fair!

It would be interesting to see if DLL injection works after this change.  I don't know the easiest way to test it other than by writing a small program that injects a test DLL...
Brad pointed this article out to me:
http://www.sekoia.fr/blog/microsoft-edge-binary-injection-mitigation-overview/

This seems to confirm my suspicions (from comment 5) that they are using some new undocumented options for SetProcessMitigationPolicy.

I don't see anything in the current Chromium code for this; I've emailed one of the Chromium sandbox guys to see if they have any plans to add it.

I note that it says they hook NtCreateSection as part of implementing the blocking.
As I understand it, this is how the Chromium sandbox implements it's DLL blacklist.

I also note that at the end of the article they suggest that if you have the right sort of privileges you can inject your code fairly easily anyway.
I've tested this with our code and can confirm that they do not consider binaries that match the cert of the executable to be permissible; Windows throws up an error as soon as Firefox attempts to load mozglue.

This feature is worth using provided that Microsoft was willing to throw us a bone. As Bob points out, it may not be 100% effective against malice, but it would be very effective against incompetence. :-)
To examine the launcher, see https://github.com/dblohm7/launchfx
Requires Windows 10 SDK 10.0.10586.0
Of course, it could be possible to set the mitigation *after* loading our DLLs, but that leaves a window of time when 3rd party libraries could still be injected. If we enabled it prior to loading user32.dll, we would be okay for AppInitDLLs and hooks, but it won't help with CreateRemoteThread or other mechanisms.
Today I exchanged emails with Crispin Cowan at Microsoft about this feature. According to him, the Right Way (TM) for us to do this is to distribute Firefox through the Windows Store, as this process mitigation also allows any DLLs that are signed for the Store.

This sounds to me like a carrot to incentivize developers to move over to the Windows Store, but nonetheless, that is the current way of things.

Updated

2 years ago
See Also: → 1378417
You need to log in before you can comment on or make changes to this bug.