Google chrome - OpenFileMapping ACCESS_DENIED

c++ / delphi package - dll injection and api hooking
EaSy
Posts: 150
Joined: Tue Oct 23, 2012 12:33 pm

Google chrome - OpenFileMapping ACCESS_DENIED

Post by EaSy »

Hi,
we have an issue with google chrome processes running at the untrusted integrity level on w81. MCH doesn't disable any hooks during the uninjection of our library. The reason is that the MCH is unable to call OpenFileMapping on the AutoUnhookMap mapped file. The get last error says ACCESS_DENIED.

I propose the same thing as in the viewtopic.php?f=7&t=28046 thread. Do not call free liberary if the AutoUnhookMap variable is NULL.

Thx,
PP
madshi
Site Admin
Posts: 10753
Joined: Sun Mar 21, 2004 5:25 pm

Re: Google chrome - OpenFileMapping ACCESS_DENIED

Post by madshi »

Argh, I hate the chrome sandbox. Why is OpenFileMapping not allowed, if the file map is already open, anyway??

Anyway, thanks for the heads-up, I'll look into this.
madshi
Site Admin
Posts: 10753
Joined: Sun Mar 21, 2004 5:25 pm

Re: Google chrome - OpenFileMapping ACCESS_DENIED

Post by madshi »

Hmmmm... While working on this I'm right now wondering:

Ok, so the AutoUnhookMap opening doesn't work. But if you call FinalizeMadCHook() in your hook dll, the APIs should still be unhooked. Unfortunately it will be done in DllMain, which is bad, but it should be done. Because of that now I'm wondering if I should really skip FreeLibrary if I can't open the AutoUnhookMap?
EaSy
Posts: 150
Joined: Tue Oct 23, 2012 12:33 pm

Re: Google chrome - OpenFileMapping ACCESS_DENIED

Post by EaSy »

It is bad because we hook LdrLoadDll. So we have deadlock. :-x

PP
madshi
Site Admin
Posts: 10753
Joined: Sun Mar 21, 2004 5:25 pm

Re: Google chrome - OpenFileMapping ACCESS_DENIED

Post by madshi »

I'm not sure I understand. Can you explain?
EaSy
Posts: 150
Joined: Tue Oct 23, 2012 12:33 pm

Re: Google chrome - OpenFileMapping ACCESS_DENIED

Post by EaSy »

Well, we are hooking LdrLoadDll and LdrUnloadDll. That hook is called in FreeLibrary.

So we end up in situation like this:
FreeLibrary()
LdrUnloadDllHook()
LdrUnloadDll()
DllMain
Unhook LdrUnloadDll - deadlock

You can ask, why do we unhook manually. It doesn't matter in this case, because it can crash in LdrUnloadDllHook aftercall anyway.
madshi
Site Admin
Posts: 10753
Joined: Sun Mar 21, 2004 5:25 pm

Re: Google chrome - OpenFileMapping ACCESS_DENIED

Post by madshi »

I don't think there should be a deadlock. When unhooking is performed in DllMain automatically by madCodeHook, then madCodeHook does *not* wait for the hook callback function to be "not in use", anymore. Instead the API hook is removed immediately without any waiting. This should work fine, on the cost of a memory leak, though. The key thing is that you should not try to unhook yourself in DllMain. Let madCodeHook do the job for you.
EaSy
Posts: 150
Joined: Tue Oct 23, 2012 12:33 pm

Re: Google chrome - OpenFileMapping ACCESS_DENIED

Post by EaSy »

Well, you are right. Deadlock is caused by manual uninjection in our code. Which normally doesn't happen, because MCH unhooks everything before DllMain.
But hypothetically... won't it crash when we hook LdrUnloadDll after the dllmain is done? LdrUnloadDll is on the callstack like in here:

Code: Select all

   9  Id: 1d20.1d88 Suspend: 0 Teb: fe6b3000 Unfrozen
ChildEBP RetAddr  Args to Child              
07cbf1a0 76cf2b83 00000000 07cbf1e4 08988524 ntdll!NtDelayExecution+0xc
07cbf208 76cf104f 000001f4 00000000 07cbf738 KERNELBASE!SleepEx+0x4b
07cbf218 61150012 000001f4 00ebd1e8 00eec750 KERNELBASE!Sleep+0xf
07cbf7a8 6115151f 00ed1bf0 07cbf814 61148c85 Guard!CCodeHook::~CCodeHook+0x4b2 [x:\madcodehook\sources\c++\ccodehook.cpp @ 1098]
07cbf7b4 61148c85 00000001 00ebd1e8 00eec750 Guard!CCodeHook::`scalar deleting destructor'+0xf
07cbf814 611481c0 611acab0 00000000 00000001 Guard!UnhookInternal+0x195 [x:\madcodehook\sources\c++\hooking.cpp @ 491]
07cbf828 610808f5 611acab0 611b3220 771f18f0 Guard!UnhookAPI+0x10 [x:\madcodehook\sources\c++\hooking.cpp @ 189]
07cbf850 610bd65c 771f22d0 00000000 60fe0000 Guard!CHooker::UnHookAllHookedFunctions+0x45 [hooker.cpp @ 371]
07cbf864 610bbf6f 00000000 00000000 00000001 Guard!CGuard::Destroy+0x6c [guard.cpp @ 649]
07cbf880 6115b08f 60fe0000 00000000 00000000 Guard!DllMain+0x21f [guard.cpp @ 135]
07cbf8c4 6115b006 60fe0000 00000000 00000000 Guard!__DllMainCRTStartup+0x82 [f:\dd\vctools\crt\crtw32\dllstuff\crtdll.c @ 508]
07cbf8d8 774f97de 60fe0000 00000000 00000000 Guard!_DllMainCRTStartup+0x1c [f:\dd\vctools\crt\crtw32\dllstuff\crtdll.c @ 472]
07cbf8f8 774f9758 6115afea 60fe0000 00000000 ntdll!LdrxCallInitRoutine+0x16
07cbf948 774cf112 00000000 00000000 0918fe35 ntdll!LdrpCallInitRoutine+0x43
07cbf9b0 774cef8f 775af720 00eaed90 00000000 ntdll!LdrpProcessDetachNode+0xbb
07cbf9d4 774cdc72 0918fd89 00000000 00000000 ntdll!LdrpUnloadNode+0x4a
07cbfa0c 7751d010 0918fdd5 00000000 717a0000 ntdll!LdrpDecrementNodeLoadCount+0xb8
07cbfa50 610ab986 60fe0000 775af76c 60fe0000 ntdll!LdrUnloadDll+0x3c
07cbfa64 717a003b 60fe0000 00000004 fe6b3000 Guard!LdrUnloadDllHook+0x66 [ldrunloaddll.cpp @ 33]
WARNING: Frame IP not in any known module. Following frames may be wrong.
07cbfa78 71b0020b 60fe0000 71b00000 71b00000 0x717a003b
07cbfe34 771f7c04 71b10000 771f7be0 096db062 0x71b0020b
07cbfe48 7750ad1f 71b10000 0918f915 00000000 kernel32!BaseThreadInitThunk+0x24
07cbfe90 7750acea ffffffff 774f0244 00000000 ntdll!__RtlUserThreadStart+0x2f
07cbfea0 00000000 71b00000 71b10000 00000000 ntdll!_RtlUserThreadStart+0x1b
We call manual unhook only in case of MCH thread manually deattaching DLL. Removing it would solve the deadlock, but would, as i understand this, introduce crashes. What do you think?

PP
madshi
Site Admin
Posts: 10753
Joined: Sun Mar 21, 2004 5:25 pm

Re: Google chrome - OpenFileMapping ACCESS_DENIED

Post by madshi »

No, FinalizeMadCHook() uses a special unhooking method which leaves a memory page allocated for each hook that is still "in use", so that each hook has a sane memory page to return to. Of course this produces a memory leak. But there should be no crash. I would recommend not to unhook manually at all. Instead let FinalizeMadCHook() do the job. Of course it would still make a lot of sense to double and triple check that everything is still stable when doing that. But I believe it should...
EaSy
Posts: 150
Joined: Tue Oct 23, 2012 12:33 pm

Re: Google chrome - OpenFileMapping ACCESS_DENIED

Post by EaSy »

Thx for the info, but I am not sure about how the LdrUnloadDllHook aftercall will behave after the DLL is unloaded. Will it be called after FinalizeMadCHook() or not?
madshi
Site Admin
Posts: 10753
Joined: Sun Mar 21, 2004 5:25 pm

Re: Google chrome - OpenFileMapping ACCESS_DENIED

Post by madshi »

The hook should not be called, anymore, after the DLL is unloaded.
EaSy
Posts: 150
Joined: Tue Oct 23, 2012 12:33 pm

Re: Google chrome - OpenFileMapping ACCESS_DENIED

Post by EaSy »

So... FinalizeMadCHook modifies the return addres of the LdrUnloadDll, so it returns not into LdrUnloadDllHook but one level in callstack higher (kernel32!BaseThreadInitThunk in this case)?
madshi
Site Admin
Posts: 10753
Joined: Sun Mar 21, 2004 5:25 pm

Re: Google chrome - OpenFileMapping ACCESS_DENIED

Post by madshi »

At least that's the intention, yes. Might still make sense to test it on your side, to make sure it's really working... :wink:
EaSy
Posts: 150
Joined: Tue Oct 23, 2012 12:33 pm

Re: Google chrome - OpenFileMapping ACCESS_DENIED

Post by EaSy »

OK, thx for the info. :idea:
EaSy
Posts: 150
Joined: Tue Oct 23, 2012 12:33 pm

Re: Google chrome - OpenFileMapping ACCESS_DENIED

Post by EaSy »

EaSy wrote:So... FinalizeMadCHook modifies the return addres of the LdrUnloadDll, so it returns not into LdrUnloadDllHook but one level in callstack higher (kernel32!BaseThreadInitThunk in this case)?
Hi,
I want to revive this thread, because we have an issue. MCH does not modify the return address of our LdrUnloadDllHook, so it crashes chrome.exe processes when uninjecting manually. Any idea why is it happening? We have your latest beta. Thx.

PP
Post Reply