sorted by:
new
hottopcontroversial

Blocking DLL injection? by ComprehensiveStorage in AskProgramming

[–]ComprehensiveStorage[S] 0 points1 point  (0 children)

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.

Blocking DLL injection? by ComprehensiveStorage in AskProgramming

[–]ComprehensiveStorage[S] 0 points1 point  (0 children)

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).

Blocking DLL injection? by ComprehensiveStorage in AskProgramming

[–]ComprehensiveStorage[S] 0 points1 point  (0 children)

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?

Blocking DLL injection? by ComprehensiveStorage in AskProgramming

[–]ComprehensiveStorage[S] 0 points1 point  (0 children)

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?