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.
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.
You need to log in before you can comment on or make changes to this bug.