SendIPC to service from DLLmain in Edge

[tbrd]

Hello!
I have a problem in Windows 10 x64 1703 (and newer insider builds). In Edge my hookdll (DLLmain) cannot send an MCH IPC message to its service. The IPC-queue has no special security descriptor and can be accessed all other (normal) processes. But in Edge the message is not sent and lastError is set to ERROR_ACCESSS_DENIED.
Has anyone (including Madshi) have a hint, whats going wrong?

[iconic]

It's part of Edge's new security design by Microsoft. Edge is divided into sub-components and each one is hosted in their own separate/isolated app container, similar to a WinRT app on Windows 8+. Things like flash and JIT code generation function independently from one another reducing the attack surface from web attacks, local or remote. Since Edge is a least-privilege based sandbox and app container it will restrict the capabilities of things like using LPC, mailslots, named pipes etc. out of the box. It's either not permitted in the ACL (as an added ACE) or the already restricted broker that governs it is disallowing this. Regardless, it's by design due to tightened security from Microsoft especially with the Windows 10 Anniversary build.

--Iconic

[madshi]

It used to work, seems they've tightened security even more now...

[iconic]

I figured that MS would eventually tighten the bolts even more so, when IE unrolled Enhanced Protected Mode (EPM) we caught a glimpse of where MS was taking their browser security. Now that Edge is the successor to IE (phasing it out) I imagine security aspects will continue to improve. What was already mentioned and very relevant is even if Edge was injected successfully (say the driver was able to inject the DLL before Edge dynamically disallowed DLL loading) it wouldn't change the fact that Edge still has dynamic code generation mitigation policies in effect so it wouldn't be helpful just to inject the DLL when you can't hook any APIs. Control Flow Guard (CFG) and Arbitrary Code Guard (ACG) are also implemented and enabled by default, at least on newer Edge versions from the Anniversary update for Windows 10. The only way to work around this would be to do everything from the driver or do this from a separate helper process but I haven't actually tested either because I'd be breaking security designed to protect my web session. Breaking security policies that are enforced to protect me the end-user doesn't make much sense to me and in doing so I could potentially open up a security hole in the process so I think that it's not a sound idea from a security standpoint. I believe that disallowing Edge to run on employee PCs is the better option

--Iconic

[madshi]

I fully agree that trying to break the new process mitigations doesn't sound like a good idea. Doing so seems like malware-like behaviour to me, and as you say, it might up security holes. I've also talked to a big anti-virus company (which is using madCodeHook) about it, and they share the same view.

A key question is at which point in time the process mitigations actually become active. Is it already before even ntdll.dll's entry point is called (or would be called, if there were one)? Or do the mitigations only become active after statically linked dlls got initialized? Maybe there's a chance to install hooks before the mitigations become active. However, if we do that, unhooking the APIs again will become tricky.

[iconic]

Main issue with injection and/or hooking is that these mitigation policies aren't just run-time calls, they can be set/put in place before the child process is spawned with UpdateThreadProcAttribute(StartupInfoEx, PROC_THREAD_ATTRIBUTE_MITIGATION_POLICY) -> CreateProcess() or set in the registry as a system setting that the PE loader will look at. So, in knowing this, the process took security tightening settings prior to even being mapped, well before execution is performed. Wouldn't hurt to test an example such as this however in the case of statically linked DLLs

https://msdn.microsoft.com/en-us/library/windows/desktop/ms686880(v=vs.85).aspx (scroll to bottom for example code)

--Iconic

[madshi]

Do you have more information about those registry settings you mentioned? Is it also possible to *disable* mitigations through that registry settings (e.g. for Edge)?

[iconic]

It's for the most part undocumented but well explained in the text below. You can add a value entry under the IFEO key and specify which mitigation policies to enable or disable per process (newly created value name would be like "Browser.exe" as an example with a value of the bitmasked QWORD value) - Yes, dynamic code policy can be adjusted here from what the text describes. This should be useful to you

https://theryuu.github.io/ifeo-mitigationoptions.txt


--Iconic

[madshi]

Thank you - that could be very useful for madCodeHook users who're willing to edit the registry to make API hooking inside of Edge possible!

[iconic]

With a disclaimer of "You've voided your own warranty if you choose to proceed"

--Iconic

[Hennemann]

It used to work, seems they've tightened security even more now...

I know, Microsoft always know how to throw a spanner in the works.