Support Binary Signature Policy and eventually Code Integrity Guard on Windows

NEW
Unassigned

Status

()

P3
normal
a year ago
22 days ago

People

(Reporter: tjr, Unassigned)

Tracking

(Depends on: 1 bug, {parity-edge, sec-want})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: sb+)

(Reporter)

Description

a year ago
Binary Signature Policy and Code Integrity Guard (CIG) are mechanisms to prevent certain dlls from being loaded. Combined with Arbitrary Code Guard (ACG) and JIT Hardening (Bug 1376819), they prevent an attacker from being able to achieve execution of arbitrary code they have written.[0] This is distinct from being able to execute arbitrary code, as it does not prevent a full ROP payload; however it is a big setback for exploit writers, as it will prevent them from VirtualAlloc-ing their payload.

Both work by preventing non-Microsoft or non-Microsoft-blessed dlls from being loaded. They were designed for Edge and the Windows App Store, so they're not as flexible as we'd like.

Binary Signature Policy is applied at runtime. CIG is applied before a process starts.  Because of the MSFT specific nature of the APIs, we may never be able to do CIG (unless MSFT gives us a whitelist API.)

BinarySignaturePolicy is set via SetProcessMitigationPolicy[1]. It supports 3 flags[2]:
- MicrosoftSignedOnly
- StoreSignedOnly
- MitigationOptIn

CIG is used via UpdateProcThreadAttribute[3] on a process you're about to launch. It supports 4 undocumented flags:
- BLOCK_NON_MICROSOFT_BINARIES_DEFER
- BLOCK_NON_MICROSOFT_BINARIES_ALWAYS_ON
- BLOCK_NON_MICROSOFT_BINARIES_ALWAYS_OFF
- BLOCK_NON_MICROSOFT_BINARIES_ALLOW_STORE


There are a few problems with turning off all non-MSFT dlls: 
- We lazy load media dlls sometimes
- Accessibility tools like screenreaders
- AV and related dll injections. (Maybe this isn't a problem at all!)

The thinking, untested, is that we might be able to preload all needed dlls, and then turn on Binary Signature Policy.


[0] https://blogs.windows.com/msedgedev/2017/02/23/mitigating-arbitrary-native-code-execution/
[1] https://msdn.microsoft.com/en-us/library/windows/desktop/hh769088(v=vs.85).aspx
[2] https://msdn.microsoft.com/en-us/library/windows/desktop/mt706242(v=vs.85).aspx
[3] https://msdn.microsoft.com/en-us/library/windows/desktop/ms686880(v=vs.85).aspx (search for 'binary signature policy')
(Reporter)

Updated

a year ago
Component: Security → Security: Process Sandboxing

Updated

a year ago
See Also: → bug 1229402
a11y tools should only be injecting into the chrome process, so we should be okay there.

Another concern would be video driver dlls.

Updated

a year ago
Whiteboard: sb+
(Reporter)

Updated

a year ago
See Also: → bug 1380335

Updated

a year ago
Priority: -- → P3

Updated

11 months ago
Depends on: 1366701
(Reporter)

Updated

7 months ago
Keywords: parity-edge
Note: the equivalent security feature on Mac for signature validation of loaded libraries is part of the 10.14 Enhanced Runtime. By default, it requires loaded libraries to be signed by Apple or the same developer ID. As an option, the restriction can be relaxed to allow libraries signed by the same Team ID or be completely disabled. We have bug 1470597 filed to enable Enhanced Runtime on Mac.
See Also: → bug 1470597

Updated

22 days ago
Depends on: 1409569

Comment 3

22 days ago
(In reply to Tom Ritter [:tjr] from comment #0)
> Binary Signature Policy is applied at runtime. CIG is applied before a
> process starts.  Because of the MSFT specific nature of the APIs, we may
> never be able to do CIG (unless MSFT gives us a whitelist API.)
> 
> BinarySignaturePolicy is set via SetProcessMitigationPolicy[1]. It supports
> 3 flags[2]:
> - MicrosoftSignedOnly
> - StoreSignedOnly
> - MitigationOptIn

We now have access to MicrosoftSignedOnly through chromium sandbox via MITIGATION_FORCE_MS_SIGNED_BINS. 

> CIG is used via UpdateProcThreadAttribute[3] on a process you're about to
> launch. It supports 4 undocumented flags:
> - BLOCK_NON_MICROSOFT_BINARIES_DEFER
> - BLOCK_NON_MICROSOFT_BINARIES_ALWAYS_ON
> - BLOCK_NON_MICROSOFT_BINARIES_ALWAYS_OFF
> - BLOCK_NON_MICROSOFT_BINARIES_ALLOW_STORE

These are defined in headers now - 

PROCESS_CREATION_MITIGATION_POLICY_BLOCK_NON_MICROSOFT_BINARIES_MASK
PROCESS_CREATION_MITIGATION_POLICY_BLOCK_NON_MICROSOFT_BINARIES_DEFER
PROCESS_CREATION_MITIGATION_POLICY_BLOCK_NON_MICROSOFT_BINARIES_ALWAYS_ON
PROCESS_CREATION_MITIGATION_POLICY_BLOCK_NON_MICROSOFT_BINARIES_ALWAYS_OFF
PROCESS_CREATION_MITIGATION_POLICY_BLOCK_NON_MICROSOFT_BINARIES_ALLOW_STORE

https://docs.microsoft.com/en-us/windows/desktop/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute
You need to log in before you can comment on or make changes to this bug.