1588243 - Our detour of ntdll!LdrLoadDll is reverted if eScan Internet Security Suite is installed

Status: NEW

(Firefox :: Launcher Process, defect, P3)

Description

[Toshihito Kikuchi [:toshi]]

In the Launcher Process Failure ping, we can see a failure of detouring ntdll!LdrLoadDll after detouring ntdll!NtMapViewOfSection succeeded.

Analyzing data more closely, in many of failure instances, avcuf64.dll (version 3.13 signed by Bitdefender SRL) was loaded into the launcher process. The behavior of that module could be a root cause.

Comment 1

[Toshihito Kikuchi [:toshi]]

I got a local repro. The latest eScan Internet Security Suite 11.0.1400.2175 contains avcuf64.dll 3.13.18462.6565.

eScan driver avc3.sys registers a callback of process creation via PsSetCreateProcessNotifyRoutineEx, which detours ntdll!LdrLoadDll by calling NtWriteVirtualMemory to inject avcuf64.dll. At the end of their detour function, it reverts their detour so that the original process will not see detoured ntdll!LdrLoadDll. However, our launcher process tries to detour a child process early, while their detour still exists. As a result, we failed to detour ntdll!LdrLoadDll.

Comment 2

[Toshihito Kikuchi [:toshi]]

Attachment: Debug log

Comment 3

[Toshihito Kikuchi [:toshi]]

I realized it's easy to detour LdrLoadDll on top of eScan's hook by updating PatchIfTargetIsRecognizedTrampoline. It stops this launcher failure, but it makes the matter worse because first time their hook runs, it reverts LdrLoadDll into the original state, meaning our hook is also eliminated. As a result we lose our protection without having launcher failures.

If we solve this, I can think of the following options but these all have some risk.

• if we detect detour, create a trampoline based on the browser process code
• restore the first several bytes of LdrLoadDll and detour
• restore the entire code section of ntdll and detour

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:aklotz, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 5

[Toshihito Kikuchi [:toshi]]

Attachment: x64 assembly after eScan's detour

Comment 6

[Toshihito Kikuchi [:toshi]]

Attachment: x86 assembly after eScan's detour

Comment 7

[Toshihito Kikuchi [:toshi]]

Here's how eScan's detour modifies ntdll!LdrLoadDll. (The entire assembly code is attached.)

Their hook function calls the original LdrLoadDll twice: the first one is to load the original dll, and the second one is to load their dll avcuf32.dll. The problem is that their code reverts the detour into the original state without any check before invoking the original LdrLoadDll.

64bit - The first 16 bytes are modified.

ntdll!LdrLoadDll:
00007ffe`f5181680 48b82504004c00000000 mov rax,4C000425h
00007ffe`f518168a 50              push    rax
00007ffe`f518168b c3              ret
00007ffe`f518168c cc              int     3
00007ffe`f518168d 90              nop
00007ffe`f518168e 90              nop
00007ffe`f518168f 90              nop
00007ffe`f5181690 488b0549be1500  mov     rax,qword ptr [ntdll!_security_cookie (00007ffe`f52dd4e0)]

32bit - The first 8 bytes are modified.

32.1: kd:x86> u 777d4c80
00000000`777d4c80 681304004c      push    4C000413h
00000000`777d4c85 c3              ret
00000000`777d4c86 cc              int     3
00000000`777d4c87 90              nop
00000000`777d4c88 83ec64          sub     esp,64h

Since our function CreateTrampoline cannot handle their 64bit detour pattern mov rax, imm64; push rax; ret, we fail to detour on top of their detour, resulting in the launcher failure.

As commented above, we can easily update PatchIfTargetIsRecognizedTrampoline so that we can detour this 64bit pattern, but it does not solve the reverting problem.

On the other hand, we are able to detour their 32bit detour pattern push imm32; ret. This means no launcher failure happens on 32bit, but we have the reverting problem.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 9

[Suhaib Mujahid [:suhaib]]

Sorry, there was a problem with the detection of inactive users. I'm reverting the change.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.