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. 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. It supports 3 flags: - MicrosoftSignedOnly - StoreSignedOnly - MitigationOptIn CIG is used via UpdateProcThreadAttribute 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.  https://blogs.windows.com/msedgedev/2017/02/23/mitigating-arbitrary-native-code-execution/  https://msdn.microsoft.com/en-us/library/windows/desktop/hh769088(v=vs.85).aspx  https://msdn.microsoft.com/en-us/library/windows/desktop/mt706242(v=vs.85).aspx  https://msdn.microsoft.com/en-us/library/windows/desktop/ms686880(v=vs.85).aspx (search for 'binary signature policy')
Component: Security → Security: Process Sandboxing
a11y tools should only be injecting into the chrome process, so we should be okay there. Another concern would be video driver dlls.
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.
(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. It supports > 3 flags: > - MicrosoftSignedOnly > - StoreSignedOnly > - MitigationOptIn We now have access to MicrosoftSignedOnly through chromium sandbox via MITIGATION_FORCE_MS_SIGNED_BINS. > CIG is used via UpdateProcThreadAttribute 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.