1306406 - (injecteject) [Meta] Mitigations for DLL Injection

Status: NEW

(Toolkit :: Startup and Profile System, defect, P2)

Description

[(No longer employed by Mozilla) Aaron Klotz]

I'm going to be spending Q4 2016 working on improving stability as it relates to DLL injection and other issues created by antivirus software.

This is a meta bug for tracking issues specifically related to the former.

Comment 1

[(No longer employed by Mozilla) Aaron Klotz]

This is from an email that I wrote to blassey:

I definitely agree that safe mode should be the most aggressive with both kernel-supported (Windows 8 and newer only, sadly) as well as user-mode mitigations. I have lots of ideas about this:

1) We should enable the "extension points" mitigation. That will disable AppInit_DLLs, Windows Hooks, a11y hooks and such (See also bug 1291353). Other injection mechanisms such as CreateRemoteThread() are more difficult to mitigate (though I have some extremist ideas about how to handle that, too)...

2) We could also enable the "require Microsoft-signed DLLs" mitigation with the caveat that it must be temporarily switched off whenever we load our own DLLs. Obviously that opens a window for abuse, but it would be quite effective for process startup injections (the ESET bug comes to mind here).

3) Make safe mode turn the blocklist into a whitelist where we only allow dlls that are either ours or part of the OS. Probably ineffective against a sufficiently motivated attacker, but more than adequate to deal with non-malicious third-parties;

4) I also think that we might want to consider grabbing call stacks of third-party dll injections and feeding them into telemetry. Since we've already hooked into the loader, we could easily do a stackwalk at that time (but only for third-party libs). Having a better understanding of the injected DLL's mechanism of attack would be beneficial for the purposes of developing mitigations.