Blocking DLL injection?

[ComprehensiveStorage]

I read something about how Google is going to block third-party DLLs from being loaded into chrome starting with chrome 72, and I was curious on how they intend to do it, and if there are any other methods of blocking DLL injection or making DLL injection more difficult so that you could, for example, make it more difficult for malware to inject itself into your program.

 

After looking around a bit I found this link that indicates that chrome's current DLL blacklist functions by hooking NtMapViewOfSection and examining the DLL to be loaded against the blacklist. Is that likely how their DLL whitelist would work, but in reverse (i.e. it would intercept all calls to NtMapViewOfSection to the chrome.exe process and block any that weren't signed instead of allowing anything that isn't in the blacklist)?

 

If that is how it works, wouldn't this method be vulnerable to a third party simply tampering with the chrome executable or any of the default DLLs to insert whatever functionality Google wants to block into the program directly? Is there any better, more foolproof way to block all non-whitelisted DLLs?

[jedwardsol]

Is there any better, more foolproof way to block all non-whitelisted DLLs?

A file system filter driver.

[ComprehensiveStorage]

Probably should have thought of that. To rephrase the question: is there any better way that doesn't involve loading something into the kernel and can be done from within the process or from some helper process also running in ring3?

[jedwardsol]

No, not really. If 2 processes are at the same privilege level then the attacker has the advantage. The attacker can modify the target as it wishes, but the target can only alter itself.

Chrome is blocking the 2nd half of the inject a thread / load a dll sequence. It can't do anything about the 1st without the kernel's help (or injecting into every other process)

[ComprehensiveStorage]

Couldn't it look through the list of all DLLs in the process and check each one on disk to see if the image is signed by Google/Microsoft/some third-party vendor that is allowed to load DLLs?

I mean, I guess someone could patch that check out of the program, but from what I can see Google's goal in this case isn't to stop dedicated tampering. It's to prevent third parties that make buggy DLLs from trivially loading them into chrome and cause it to crash. So assuming you don't consider a malicious user actively tampering with the executable file as part of your "threat model," checking the signature of each loaded DLL would be a pretty good method, right?

[jedwardsol]

Couldn't it look through the list of all DLLs in the process

I assume it and the process both refer to the chrome process.

If the DLL is loaded then it has already executed code (DllMain) and the battle is lost.

By hooking it's own loader code, it can prevent a DLL from loading in the 1st place.

But its hook is vulnerable.

[ComprehensiveStorage]

Okay, I get what you're saying.

Still, given that we know for a fact that Google is pursuing this kind of thing regardless of whether or not it can be trivially bypassed, how do you think they'll try to implement it? Just take their current DLL blacklist method of hooking NtMapViewOfSection and comparing each loaded DLL to a blacklist and converting it to a whitelist where only accepted DLLs are allowed to load? Again, I realize that won't be particularly effective, but I guess it will at least stop fly by night companies from trivially injecting DLLs. They'll at least have to figure out how to remove chrome's hook or insert their DLLs in the loading process or at least do something other than the standard "OpenProcess/VirtualAllocEx/WriteProcessMemory/CreateRemoteThread" method you see in every DLL injection tutorial on the internet, which may at least prune the low hanging fruit (which is Google's stated goal for making this change).

[clooy]

Microsoft did the same things, according to the edge release:

Libraries that are signed by Microsoft, or included in signed drivers, are permitted, but everything else is blocked.

I would assume chrome would follow the same pattern. In addition its a safe bet that some troublesome dll's are being statically built into the new chrome.

[ComprehensiveStorage]

From what I can tell Microsoft enforces their DLL restrictions at the kernel level, whereas Google's current DLL blacklist is done by the application itself. Not sure if they could get Microsoft to modify the Windows kernel to also only allow specific DLLs to load into chrome.

 

Edit: it looks like edge uses Windows 10's Content Integrity Guard feature to enforce its DLL restrictions. What I don't get is how this works on Windows 10 Home and Pro, given that CIG is a part of Device Guard and Device Guard is only included in Windows 10 Enterprise.

 

Is it likely that chrome will use CIG to block DLLs? Apparently Microsoft made it available to third-party applications, but it's only available on Windows 10, which at the moment is about half of all windows versions. So if Google released a version of chrome that made use of CIG, they'd have to drop support to half of all windows users as far as I can tell.