Investigate use of Process Mitigation Policy to improve DLL blocklisting

NEW
Unassigned

Status

()

Toolkit
Startup and Profile System
P1
normal
2 years ago
9 months ago

People

(Reporter: aklotz, Unassigned)

Tracking

({stale-bug})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: tpi:+)

(Reporter)

Description

2 years ago
One consistent problem that we've had with the DLL blocklist is that it ideally needs to be initialized before user32.dll is loaded. This is necessary to prevent AppInit_DLLs, Windows Hooks, a11y hooks, etc from injecting DLLs prior to blocklist readiness.

Starting with Windows 8, I think that we can relax this requirement while improving our blocklist coverage:

1) Observe that it's not the presence of user32.dll that we *really* care about, but rather its side effects (injection);
2) Those side effects may be controlled by SetProcessMitigationPolicy and PROC_THREAD_ATTRIBUTE_MITIGATION_POLICY;
3) We are hesitant to outright block all dll injection due to its use by a11y, video drivers, etc....

BUT: beginning with Windows 8, we *can* set that policy temporarily until the blocklist has been loaded, and then disable it again, thus allowing us to be able to temporarily suppress user32-facilitated DLL injection until after the blocklist has been initialized.

I see this as working as follows:

1) firefox.exe checks for the presence of user32.dll prior to loading the blocklist.

2) If user32.dll is already there, we need to restart ourselves by relaunching firefox via CreateProcess, setting a thread attribute list that includes PROC_THREAD_ATTRIBUTE_MITIGATION_POLICY with ProcessExtensionPointDisablePolicy being turned on.

3) Once the DLL blocklist has initialized, we call SetProcessMitigationPolicy and disable ProcessExtensionPointDisablePolicy, this re-enabling injection.

Updated

2 years ago
Priority: -- → P1
Whiteboard: tpi:+
Did we look how Chromium manages that?
Comment hidden (obsolete)
You need to log in before you can comment on or make changes to this bug.