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