What Were They Thinking?
Anti-Virus Software Gone Wrong
Skywing
[email protected]
0. Foreword
Abstract: Anti-virus software is becoming more and more prevalent on end-user
computers today. Many major computer vendors (such as Dell) bundle anti-virus
software and other personal security suites in the default configuration of
newly-sold computer systems. As a result, it is becoming increasingly important
that anti-virus software be well-designed, secure by default, and interoperable
with third-party applications. Software that is installed and running by
default constitutes a prime target for attack and, as such, it is especially
important that said software be designed with security and interoperability in
mind. In particular, this article provides examples of issues found in
well-known anti-virus products. These issues range from not properly validating
input from an untrusted source (especially within the context of a kernel
driver) to failing to conform to API contracts when hooking or implementing an
intermediary between applications and the underlying APIs upon which they rely.
For popular software, or software that is installed by default, errors of this
sort can become a serious problem to both system stability and security. Beyond
that, it can impact the ability of independent software vendors to deploy
functioning software on end-user systems.
1. Introduction
In today's computing environment, computer security is becoming a more and more
important role. The Internet poses unique dangers to networked computers, as
threats such as viruses, worms, and other malicious software become more and
more common.
As a result, there has been a shift towards including personal security
software on most new computers sold today, such as firewall software and
anti-virus software. Many new computers are operated and administered by
individuals who are not experienced or savvy with the administration of a
secure system, and as such rely solely on the protection provided by a firewall
or anti-virus security suite.
Given this, one would expect that firewall, anti-virus, and other personal
security software would be high quality - after all, for many individuals,
firewall and anti-virus software are the first (and all-too-often only) line
of defense.
Unfortunately, though, most common anti-virus and personal firewall software is
full of defects that can at best make it very difficult to interoperate with
(which turns out to be a serious problem for most software vendors, given how
common anti-virus and firewall software is), and at worst compromise the very
system security they advertise to protect.
This article discusses two personal security software packages that suffer from
problems that make it difficult to interoperate with the software, or even
compromise system security, all due to shortcuts and unsafe assumptions made by
the original developers.
- Kaspersky Internet Security Suite 5.0
- McAfee Internet Security Suite 2006
Both of these software packages include several personal security programs,
including firewall and anti-virus software.
2. The problem: Kaspersky Internet Security Suite 5.0
Kaspersky ships a personal security software suite known as Kaspersky Internet
Security Suite 5.0. This package includes various personal security software
programs, including a firewall and anti-virus software.
Kaspersky's anti-virus software is the primarily focus of this article. Like
many other anti-virus software, Kaspersky Anti-Virus provides both manual and
real-time scanning capabilities.
Kaspersky's anti-virus system (KAV) employs various unsafe techniques in its
kernel mode components, which may lead to a compromise of system security.
2.1. Patching system services at runtime.
Although KAV appears to use a filesystem filter, the standard Windows mechanism
for intercepting accesses to files (specifically designed for applications like
anti-virus software), the implementors also used a series of API-level function
hooks to intercept various file accesses. Performing function hooking in
kernel mode is a dangerous proposition; one must be very careful to fully
validate all parameters if a function could be called from user mode (otherwise
system security could be compromised by a malicious unprivileged program).
Additionally, it is generally not safe to remove code hooks in kernel mode as
it is difficult to prove that no threads will be running a particular code
region in order to unhook without risking bringing down the system. KAV also
hooks several other system services in a misguided attempt to "protect" its
processes from debuggers and process termination.
Unfortunately, the KAV programmers did not properly validate parameters passed
to hooked system calls, opening holes that, at the very least, allow unprivileged
user mode programs to bring down the system, and may even allow local privilege
escalation (though the author has not spent the time necessary to prove whether
such is possible).
KAV hooks the following system services (easily discoverable in WinDbg by
comparing nt!KeServiceDescriptorTableShadow on a system with KAV loaded with a
clean system:
kd> dps poi ( nt!KeServiceDescriptorTableShadow ) l dwo ( nt!KeServiceDescriptorTableShadow + 8 )
8191c9c8 805862de nt!NtAcceptConnectPort
8191c9cc 8056fded nt!NtAccessCheck
.
.
.
8191ca2c f823fd00 klif!KavNtClose
.
.
.
8191ca84 f823fa20 klif!KavNtCreateProcess
8191ca88 f823fb90 klif!KavNtCreateProcessEx
8191ca8c 80647b59 nt!NtCreateProfile
8191ca90 f823fe40 klif!KavNtCreateSection
8191ca94 805747cf nt!NtCreateSemaphore
8191ca98 8059d4db nt!NtCreateSymbolicLinkObject
8191ca9c f8240630 klif!KavNtCreateThread
8191caa0 8059a849 nt!NtCreateTimer
.
.
.
8191cbb0 f823f7b0 klif!KavNtOpenProcess
.
.
.
8191cc24 f82402f0 klif!KavNtQueryInformationFile
.
.
.
8191cc7c f8240430 klif!KavNtQuerySystemInformation
.
.
.
8191cd00 f82405e0 klif!KavNtResumeThread
.
.
.
8191cd58 f82421f0 klif!KavNtSetInformationProcess
.
.
.
8191cdc0 f8240590 klif!KavNtSuspendThread
.
.
.
8191cdcc f82401c0 klif!KavNtTerminateProcess
Additionally, KAV attempts to create several entirely new system services as a
shortcut for calling kernel mode by patching the service descriptor table.
This is certainly not the preferred mechanism to allow a user mode program to
communicate with a driver; the programmers should have used the conventional
IOCTL interface, which avoids the pitfalls of patching kernel structures at
runtime and having to deal with other inconveniences such as system service
ordinals changing from OS release to OS release.
2.2. Improper validation of user mode pointers, assuming the size of the kernel
address space.
Many of the hooks that KAV installs (and even the custom system services)
suffer from flaws that are detrimental to the operation of the system.
For instance, KAV's modified NtOpenProcess attempts to determine if a user
address is valid by comparing it to the hardcoded value 0x7FFF0000. On most
x86 Windows systems, this address is below the highest user address (typically
0x7FFEFFFF). However, hardcoding the size of the kernel address space is not a
very good idea; there is a boot parameter `/3GB' that can be set in boot.ini in
order to change the default address space split of 2GB kernel and 2GB user to
1GB kernel and 3GB user. If a system with KAV is configured with /3GB, it is
expected that anything that calls NtOpenProcess (such as the win32 OpenProcess)
may randomly fail if parameter addresses are located above the first 2GB of the
user address space:
.text:F82237B0 ; NTSTATUS __stdcall KavNtOpenProcess(PHANDLE ProcessHandle,ACCESS_MASK DesiredAccess,POBJECT_ATTRIBUTES ObjectAttributes,PCLIENT_ID ClientId)
.text:F82237B0 KavNtOpenProcess proc near ; DATA XREF: sub_F82249D0+BFo
.
.
.
.text:F8223800 cmp eax, 7FFF0000h ; eax = ClientId
.text:F8223805 jbe short loc_F822380D
.text:F8223807
.text:F8223807 loc_F8223807: ; CODE XREF: KavNtOpenProcess+4Ej
.text:F8223807 call ds:ExRaiseAccessViolation
The proper way to perform this validation would have been to use the documented
ProbeForRead function with a SEH frame, which will automatically raise an
access violation if the address is not a valid user address.
Additionally, many of KAV's custom system services do not properly validate
user mode pointer arguments, which could be used to bring down the system:
.text:F8222BE0 ; int __stdcall KAVService10(int,PVOID OutputBuffer,int)
.text:F8222BE0 KAVService10 proc near ; DATA XREF: .data:F8227D14o
.text:F8222BE0
.text:F8222BE0 arg_0 = dword ptr 4
.text:F8222BE0 OutputBuffer = dword ptr 8
.text:F8222BE0 arg_8 = dword ptr 0Ch
.text:F8222BE0
.text:F8222BE0 mov edx, [esp+OutputBuffer]
.text:F8222BE4 push esi
.text:F8222BE5 mov esi, [esp+4+arg_8]
.text:F8222BE9 lea ecx, [esp+4+arg_8]
.text:F8222BED push ecx ; int
.text:F8222BEE mov eax, [esi] ; Unvalidated user mode pointer access
.text:F8222BF0 mov [esp+8+arg_8], eax
.text:F8222BF4 push eax ; OutputBufferLength
.text:F8222BF5 mov eax, [esp+0Ch+arg_0]
.text:F8222BF9 push edx ; OutputBuffer
.text:F8222BFA push eax ; int
.text:F8222BFB call sub_F821F9A0 ; This routine internally assumes that all pointer parameters given are valid.
.text:F8222C00 mov edx, [esi]
.text:F8222C02 mov ecx, [esp+4+arg_8]
.text:F8222C06 cmp ecx, edx
.text:F8222C08 jbe short loc_F8222C13
.text:F8222C0A mov eax, 0C0000173h
.text:F8222C0F pop esi
.text:F8222C10 retn 0Ch
.text:F8222C13 ; ---------------------------------------------------------------------------
.text:F8222C13
.text:F8222C13 loc_F8222C13: ; CODE XREF: KAVService10+28j
.text:F8222C13 mov [esi], ecx
.text:F8222C15 pop esi
.text:F8222C16 retn 0Ch
.text:F8222C16 KAVService10 endp
.text:F8222C20 KAVService11 proc near ; DATA XREF: .data:F8227D18o
.text:F8222C20
.text:F8222C20 arg_0 = dword ptr 4
.text:F8222C20 arg_4 = dword ptr 8
.text:F8222C20 arg_8 = dword ptr 0Ch
.text:F8222C20
.text:F8222C20 mov edx, [esp+arg_4]
.text:F8222C24 push esi
.text:F8222C25 mov esi, [esp+4+arg_8]
.text:F8222C29 lea ecx, [esp+4+arg_8]
.text:F8222C2D push ecx
.text:F8222C2E mov eax, [esi] ; Unvalidated user mode pointer access
.text:F8222C30 mov [esp+8+arg_8], eax
.text:F8222C34 push eax
.text:F8222C35 mov eax, [esp+0Ch+arg_0]
.text:F8222C39 push edx
.text:F8222C3A push eax
.text:F8222C3B call sub_F8214CE0 ; This routine internally assumes that all pointer parameters given are valid.
.text:F8222C40 test eax, eax
.text:F8222C42 jnz short loc_F8222C59
.text:F8222C44 mov ecx, [esp+4+arg_8]
.text:F8222C48 mov edx, [esi]
.text:F8222C4A cmp ecx, edx
.text:F8222C4C jbe short loc_F8222C57
.text:F8222C4E mov eax, STATUS_INVALID_BLOCK_LENGTH
.text:F8222C53 pop esi
.text:F8222C54 retn 0Ch
.text:F8222C57 ; ---------------------------------------------------------------------------
.text:F8222C57
.text:F8222C57 loc_F8222C57: ; CODE XREF: KAVService11+2Cj
.text:F8222C57 mov [esi], ecx
.text:F8222C59
.text:F8222C59 loc_F8222C59: ; CODE XREF: KAVService11+22j
.text:F8222C59 pop esi
.text:F8222C5A retn 0Ch
.text:F8222C5A KAVService11 endp
2.3. Improper validation of user mode structures and pointers, hiding threads
from user mode.
KAV's errors with hooking do not end with NtOpenProcess, however. One of the
system services KAV hooks is NtQuerySystemInformation, which is modified to
sometimes truncate a thread listing from certain processes when the
SystemProcessesAndThreads information class is requested. This is the
underlying mechanism for user mode to receive a process and thread listing of
all programs running in the system, and in effect provides a means for KAV to
hide threads from user mode. The very fact that this code exists at all in KAV
is curious; hiding running code from user mode is typically something that is
associated with rootkits and not anti-virus software.
Besides the potentially abusive behavior of hiding running code, this hook
contains several security flaws:
1. It uses the user mode output buffer from NtQuerySystemInformation after it
has been filled by the actual kernel implementation, but it does not guard
against a malicious user mode program modifying this buffer or even freeing
it. There is no SEH frame wrapping this function, so a user mode program
could cause KAV to touch freed memory.
2. There is no validation of offsets within the returned output buffer to
ensure that offsets do not refer to memory outside of the output buffer.
This is problematic, because the returned data structure is actually a list
of sub-structures that must be walked by adding an offset supplied as part
of a particular substructure to the address of that substructure in order to
reach the next substructure. Such an offset could be modified by user mode
to actually point into kernel memory. Because the hook then sometimes
writes data into what it believes is the user mode output buffer, this is an
interesting avenue to explore for gaining kernel privileges from an
unprivileged user mode function.
.text:F8224430 ; NTSTATUS __stdcall KavNtQuerySystemInformation(SYSTEM_INFORMATION_CLASS SystemInformationClass,PVOID SystemInformation,ULONG SystemInformationLength,PULONG ReturnLength)
.text:F8224430 KavNtQuerySystemInformation proc near ; DATA XREF: sub_F82249D0+17Bo
.text:F8224430
.text:F8224430 var_10 = dword ptr -10h
.text:F8224430 var_C = dword ptr -0Ch
.text:F8224430 var_8 = dword ptr -8
.text:F8224430 SystemInformationClass= dword ptr 4
.text:F8224430 SystemInformation= dword ptr 8
.text:F8224430 SystemInformationLength= dword ptr 0Ch
.text:F8224430 ReturnLength = dword ptr 10h
.text:F8224430 arg_24 = dword ptr 28h
.text:F8224430
.text:F8224430 mov eax, [esp+ReturnLength]
.text:F8224434 mov ecx, [esp+SystemInformationLength]
.text:F8224438 mov edx, [esp+SystemInformation]
.text:F822443C push ebx
.text:F822443D push ebp
.text:F822443E push esi
.text:F822443F mov esi, [esp+0Ch+SystemInformationClass]
.text:F8224443 push edi
.text:F8224444 push eax
.text:F8224445 push ecx
.text:F8224446 push edx
.text:F8224447 push esi
.text:F8224448 call OrigNtQuerySystemInformation
.text:F822444E mov edi, eax
.text:F8224450 cmp esi, SystemProcessesAndThreadsInformation ;
.text:F8224450 ; Not the process / thread list API?
.text:F8224450 ; Return to caller
.text:F8224453 mov [esp+10h+ReturnLength], edi
.text:F8224457 jnz ret_KavNtQuerySystemInformation
.text:F822445D xor ebx, ebx
.text:F822445F cmp edi, ebx ;
.text:F822445F ; Nothing returned?
.text:F822445F ; Return to caller
.text:F8224461 jl ret_KavNtQuerySystemInformation
.text:F8224467 push ebx
.text:F8224468 push 9
.text:F822446A push 8
.text:F822446C call sub_F8216730
.text:F8224471 test al, al
.text:F8224473 jz ret_KavNtQuerySystemInformation
.text:F8224479 mov ebp, g_KavDriverData
.text:F822447F mov ecx, [ebp+0Ch]
.text:F8224482 lea edx, [ebp+48h]
.text:F8224485 inc ecx
.text:F8224486 mov [ebp+0Ch], ecx
.text:F8224489 mov ecx, ebp
.text:F822448B call ds:ExInterlockedPopEntrySList
.text:F8224491 mov esi, eax
.text:F8224493 cmp esi, ebx
.text:F8224495 jnz short loc_F82244B7
.text:F8224497 mov eax, [ebp+10h]
.text:F822449A mov ecx, [ebp+24h]
.text:F822449D mov edx, [ebp+1Ch]
.text:F82244A0 inc eax
.text:F82244A1 mov [ebp+10h], eax
.text:F82244A4 mov eax, [ebp+20h]
.text:F82244A7 push eax
.text:F82244A8 push ecx
.text:F82244A9 push edx
.text:F82244AA call [ebp+arg_24]
.text:F82244AD mov esi, eax
.text:F82244AF cmp esi, ebx
.text:F82244B1 jz ret_KavNtQuerySystemInformation
.text:F82244B7
.text:F82244B7 loc_F82244B7: ; CODE XREF: KavNtQuerySystemInformation+65j
.text:F82244B7 mov edi, [esp+10h+SystemInformation]
.text:F82244BB mov dword ptr [esi], 8
.text:F82244C1 mov dword ptr [esi+4], 9
.text:F82244C8 mov [esi+8], ebx
.text:F82244CB mov [esi+34h], ebx
.text:F82244CE mov dword ptr [esi+3Ch], 1
.text:F82244D5 mov [esi+10h], bl
.text:F82244D8 mov [esi+30h], ebx
.text:F82244DB mov [esi+0Ch], ebx
.text:F82244DE mov [esi+38h], ebx
.text:F82244E1 mov ebp, 13h
.text:F82244E6
.text:F82244E6 LoopThreadProcesses: ; CODE XREF: KavNtQuerySystemInformation+ECj
.text:F82244E6 mov dword ptr [esi+40h], 4 ;
.text:F82244E6 ; Loop through the returned list of processes and threads.
.text:F82244E6 ; For each process, we shall check to see if it is a
.text:F82244E6 ; special (protected) process. If so, then we might
.text:F82244E6 ; decide to remove its threads from the listing returned
.text:F82244E6 ; by setting the thread count to zero.
.text:F82244ED mov [esi+48h], ebx
.text:F82244F0 mov [esi+44h], ebp
.text:F82244F3 mov eax, [edi+SYSTEM_PROCESSES.ProcessId]
.text:F82244F6 push ebx
.text:F82244F7 push esi
.text:F82244F8 mov [esi+4Ch], eax
.text:F82244FB call KavCheckProcess
.text:F8224500 cmp eax, 7
.text:F8224503 jz short CheckNextThreadProcess
.text:F8224505 cmp eax, 1
.text:F8224508 jz short CheckNextThreadProcess
.text:F822450A cmp eax, ebx
.text:F822450C jz short CheckNextThreadProcess
.text:F822450E mov [edi+SYSTEM_PROCESSES.ThreadCount], ebx ; Zero thread count out (hide process threads)
.text:F8224511
.text:F8224511 CheckNextThreadProcess: ; CODE XREF: KavNtQuerySystemInformation+D3j
.text:F8224511 ; KavNtQuerySystemInformation+D8j ...
.text:F8224511 mov eax, [edi+SYSTEM_PROCESSES.NextEntryDelta]
.text:F8224513 cmp eax, ebx
.text:F8224515 setz cl
.text:F8224518 add edi, eax
.text:F822451A cmp cl, bl
.text:F822451C jz short LoopThreadProcesses
2.4. Improper validation of kernel object types.
Windows exposes many kernel features through a series of "kernel objects",
which may be acted upon by user mode through the user of handles. Handles are
integral values that are translated by the kernel into pointers to a particular
object upon which something (typically a system service) interacts with on
behalf of a caller. All objects share the same handle namespace.
Because of this handle namespace sharing between objects of different types,
one of the jobs of a system service inspecting a handle is to verify that the
object that it refers to is of the expected type. This is accomplished by an
object manager routine ObReferenceObjectByHandle, which performs the
translation of handles to object pointers and does an optional built-in type
check by comparing a type field in the standard object header to a passed in
type.
Since KAV hooks system services, in inevitably must deal with kernel handles.
Unfortunately, it does not do so correctly. In some cases, it does not ensure
that a handle refers to an object of a particular type before using the object
pointer, which will result in corruption or a system crash if a handle of the
wrong type is passed to a system service.
One such case is the KAV NtResumeThread hook, which attempts to track the state
of running threads in the system. In this particular case, it does not seem
possible for user mode to crash the system by passing an object of the wrong
type as the returned object pointer, because it is simply used as a key in a
lookup table that is prepopulated with thread object pointers. KAV also hooks
NtSuspendThread for similar purposes, and this hook has the same problem with
the validation of object handle types.
.text:F82245E0 ; NTSTATUS __stdcall KavNtResumeThread(HANDLE ThreadHandle,PULONG PreviousSuspendCount)
.text:F82245E0 KavNtResumeThread proc near ; DATA XREF: sub_F82249D0+FBo
.text:F82245E0
.text:F82245E0 ThreadHandle = dword ptr 8
.text:F82245E0 PreviousSuspendCount= dword ptr 0Ch
.text:F82245E0
.text:F82245E0 push esi
.text:F82245E1 mov esi, [esp+ThreadHandle]
.text:F82245E5 test esi, esi
.text:F82245E7 jz short loc_F8224620
.text:F82245E9 lea eax, [esp+ThreadHandle] ;
.text:F82245E9 ; This should pass an object type here!
.text:F82245ED push 0 ; HandleInformation
.text:F82245EF push eax ; Object
.text:F82245F0 push 0 ; AccessMode
.text:F82245F2 push 0 ; ObjectType
.text:F82245F4 push 0F0000h ; DesiredAccess
.text:F82245F9 push esi ; Handle
.text:F82245FA mov [esp+18h+ThreadHandle], 0
.text:F8224602 call ds:ObReferenceObjectByHandle
.text:F8224608 test eax, eax
.text:F822460A jl short loc_F8224620
.text:F822460C mov ecx, [esp+ThreadHandle]
.text:F8224610 push ecx
.text:F8224611 call KavUpdateThreadRunningState
.text:F8224616 mov ecx, [esp+ThreadHandle] ; Object
.text:F822461A call ds:ObfDereferenceObject
.text:F8224620
.text:F8224620 loc_F8224620: ; CODE XREF: KavNtResumeThread+7j
.text:F8224620 ; KavNtResumeThread+2Aj
.text:F8224620 mov edx, [esp+PreviousSuspendCount]
.text:F8224624 push edx
.text:F8224625 push esi
.text:F8224626 call OrigNtResumeThread
.text:F822462C pop esi
.text:F822462D retn 8
.text:F822462D KavNtResumeThread endp
.text:F822462D
.text:F8224590 ; NTSTATUS __stdcall KavNtSuspendThread(HANDLE ThreadHandle,PULONG PreviousSuspendCount)
.text:F8224590 sub_F8224590 proc near ; DATA XREF: sub_F82249D0+113o
.text:F8224590
.text:F8224590 ThreadHandle = dword ptr 8
.text:F8224590 PreviousSuspendCount= dword ptr 0Ch
.text:F8224590
.text:F8224590 push esi
.text:F8224591 mov esi, [esp+ThreadHandle]
.text:F8224595 test esi, esi
.text:F8224597 jz short loc_F82245D0
.text:F8224599 lea eax, [esp+ThreadHandle] ;
.text:F8224599 ; This should pass an object type here!
.text:F822459D push 0 ; HandleInformation
.text:F822459F push eax ; Object
.text:F82245A0 push 0 ; AccessMode
.text:F82245A2 push 0 ; ObjectType
.text:F82245A4 push 0F0000h ; DesiredAccess
.text:F82245A9 push esi ; Handle
.text:F82245AA mov [esp+18h+ThreadHandle], 0
.text:F82245B2 call ds:ObReferenceObjectByHandle
.text:F82245B8 test eax, eax
.text:F82245BA jl short loc_F82245D0
.text:F82245BC mov ecx, [esp+ThreadHandle]
.text:F82245C0 push ecx
.text:F82245C1 call KavUpdateThreadSuspendedState
.text:F82245C6 mov ecx, [esp+ThreadHandle] ; Object
.text:F82245CA call ds:ObfDereferenceObject
.text:F82245D0
.text:F82245D0 loc_F82245D0: ; CODE XREF: sub_F8224590+7j
.text:F82245D0 ; sub_F8224590+2Aj
.text:F82245D0 mov edx, [esp+PreviousSuspendCount]
.text:F82245D4 push edx
.text:F82245D5 push esi
.text:F82245D6 call OrigNtSuspendThread
.text:F82245DC pop esi
.text:F82245DD retn 8
.text:F82245DD sub_F8224590 endp
.text:F82245DD
Not all of KAV's hooks are so fortunate, however. The NtTerminateProcess hook
that KAV installs looks into the body of the object referred to by the process
handle parameter of the function in order to determine the name of the process
being terminated. However, KAV fails to validate that the object handle given
by user mode really refers to a process object.
This is unsafe for several reasons, which may be well known to the reader if
one is experienced with Windows kernel programming.
1. The kernel process structure definition (EPROCESS) changes frequently from
OS release to OS release, and even between service packs. As a result, it
is not generally safe to access this structure directly.
2. Because KAV does not perform proper type checking, it is possible to pass an
object handle to a different kernel object - say, a mutex - which may cause
KAV to bring down the system because the internal object structures of a
mutex (or any other kernel object) are not compatible with that of a process
object.
KAV attempts to work around the first problem by attempting to discover the
offset of the member in the EPROCESS structure that contains the process name
at runtime. The algorithm used is to scan forward one byte at a time from the
start of the process object pointer until a sequence of bytes identifying the
name of the initial system process is discovered. (This routine is called in
the context of the initial system process).
.text:F82209E0 KavFindEprocessNameOffset proc near ; CODE XREF: sub_F8217A60+FCp
.text:F82209E0 push ebx
.text:F82209E1 push esi
.text:F82209E2 push edi
.text:F82209E3 call ds:IoGetCurrentProcess
.text:F82209E9 mov edi, ds:strncmp
.text:F82209EF mov ebx, eax
.text:F82209F1 xor esi, esi
.text:F82209F3
.text:F82209F3 loc_F82209F3: ; CODE XREF: KavFindEprocessNameOffset+2Ej
.text:F82209F3 lea eax, [esi+ebx]
.text:F82209F6 push 6 ; size_t
.text:F82209F8 push eax ; char *
.text:F82209F9 push offset aSystem ; "System"
.text:F82209FE call edi ; strncmp
.text:F8220A00 add esp, 0Ch
.text:F8220A03 test eax, eax
.text:F8220A05 jz short loc_F8220A16
.text:F8220A07 inc esi
.text:F8220A08 cmp esi, 3000h
.text:F8220A0E jl short loc_F82209F3
.text:F8220A10 pop edi
.text:F8220A11 pop esi
.text:F8220A12 xor eax, eax
.text:F8220A14 pop ebx
.text:F8220A15 retn
.text:F8220A16 ; ---------------------------------------------------------------------------
.text:F8220A16
.text:F8220A16 loc_F8220A16: ; CODE XREF: KavFindEprocessNameOffset+25j
.text:F8220A16 mov eax, esi
.text:F8220A18 pop edi
.text:F8220A19 pop esi
.text:F8220A1A pop ebx
.text:F8220A1B retn
.text:F8220A1B KavFindEprocessNameOffset endp
.text:F8217B5C call KavFindEprocessNameOffset
.text:F8217B61 mov g_EprocessNameOffset, eax
Given a handle to an object of the wrong type, KAV will read from the returned
object body pointer in an attempt to determine the name of the process being
destroyed. This will typically run off the end of the structure for an object
that is not a process object (the Process object is very large compared to some
objects, such as a Mutex object, and the offset of the process name within this
structure is typically several hundred bytes or more). It is expected that
this will cause the system to crash if a bad handle is passed to
NtTerminateProcess.
.text:F82241C0 ; NTSTATUS __stdcall KavNtTerminateProcess(HANDLE ThreadHandle,NTSTATUS ExitStatus)
.text:F82241C0 KavNtTerminateProcess proc near ; DATA XREF: sub_F82249D0+ABo
.text:F82241C0
.text:F82241C0 var_58 = dword ptr -58h
.text:F82241C0 ProcessObject = dword ptr -54h
.text:F82241C0 ProcessData = KAV_TERMINATE_PROCESS_DATA ptr -50h
.text:F82241C0 var_4 = dword ptr -4
.text:F82241C0 ProcessHandle = dword ptr 4
.text:F82241C0 ExitStatus = dword ptr 8
.text:F82241C0
.text:F82241C0 sub esp, 54h
.text:F82241C3 push ebx
.text:F82241C4 xor ebx, ebx
.text:F82241C6 push esi
.text:F82241C7 mov [esp+5Ch+ProcessObject], ebx
.text:F82241CB call KeGetCurrentIrql
.text:F82241D0 mov esi, [esp+5Ch+ProcessHandle]
.text:F82241D4 cmp al, 2 ;
.text:F82241D4 ; IRQL >= DISPATCH_LEVEL? Abort
.text:F82241D4 ; ( This is impossible for a system service )
.text:F82241D6 jnb Ret_KavNtTerminateProcess
.text:F82241DC cmp esi, ebx ;
.text:F82241DC ; Null process handle? Abort
.text:F82241DE jz Ret_KavNtTerminateProcess
.text:F82241E4 call PsGetCurrentProcessId
.text:F82241E9 mov [esp+5Ch+ProcessData.CurrentProcessId], eax
.text:F82241ED xor eax, eax
.text:F82241EF cmp esi, 0FFFFFFFFh
.text:F82241F2 push esi ; ProcessHandle
.text:F82241F3 setnz al
.text:F82241F6 dec eax
.text:F82241F7 mov [esp+60h+ProcessData.TargetIsCurrentProcess], eax
.text:F82241FB call KavGetProcessIdFromProcessHandle
.text:F8224200 lea ecx, [esp+5Ch+ProcessObject] ; Object
.text:F8224204 push ebx ; HandleInformation
.text:F8224205 push ecx ; Object
.text:F8224206 push ebx ; AccessMode
.text:F8224207 push ebx ; ObjectType
.text:F8224208 push 0F0000h ; DesiredAccess
.text:F822420D push esi ; Handle
.text:F822420E mov [esp+74h+ProcessData.TargetProcessId], eax
.text:F8224212 mov [esp+74h+var_4], ebx
.text:F8224216 call ds:ObReferenceObjectByHandle
.text:F822421C test eax, eax
.text:F822421E jl short loc_F8224246
.text:F8224220 mov edx, [esp+5Ch+ProcessObject]
.text:F8224224 mov eax, g_EprocessNameOffset
.text:F8224229 add eax, edx
.text:F822422B push 40h ; size_t
.text:F822422D lea ecx, [esp+60h+ProcessData.ProcessName]
.text:F8224231 push eax ; char *
.text:F8224232 push ecx ; char *
.text:F8224233 call ds:strncpy
.text:F8224239 mov ecx, [esp+68h+ProcessObject]
.text:F822423D add esp, 0Ch
.text:F8224240 call ds:ObfDereferenceObject
.text:F8224246
.text:F8224246 loc_F8224246: ; CODE XREF: KavNtTerminateProcess+5Ej
.text:F8224246 cmp esi, 0FFFFFFFFh
.text:F8224249 jnz short loc_F8224255
.text:F822424B mov edx, [esp+5Ch+ProcessData.TargetProcessId]
.text:F822424F push edx
.text:F8224250 call sub_F8226710
.text:F8224255
.text:F8224255 loc_F8224255: ; CODE XREF: KavNtTerminateProcess+89j
.text:F8224255 lea eax, [esp+5Ch+ProcessData]
.text:F8224259 push ebx ; int
.text:F822425A push eax ; ProcessData
.text:F822425B call KavCheckTerminateProcess
.text:F8224260 cmp eax, 7
.text:F8224263 jz short loc_F822427D
.text:F8224265 cmp eax, 1
.text:F8224268 jz short loc_F822427D
.text:F822426A cmp eax, ebx
.text:F822426C jz short loc_F822427D
.text:F822426E mov esi, STATUS_ACCESS_DENIED
.text:F8224273 mov eax, esi
.text:F8224275 pop esi
.text:F8224276 pop ebx
.text:F8224277 add esp, 54h
.text:F822427A retn 8
.text:F822427D ; ---------------------------------------------------------------------------
.text:F822427D
.text:F822427D loc_F822427D: ; CODE XREF: KavNtTerminateProcess+A3j
.text:F822427D ; KavNtTerminateProcess+A8j ...
.text:F822427D mov eax, [esp+5Ch+ProcessData.TargetProcessId]
.text:F8224281 cmp eax, 1000h
.text:F8224286 jnb short loc_F8224296
.text:F8224288 mov dword_F8228460[eax*8], ebx
.text:F822428F mov byte_F8228464[eax*8], bl
.text:F8224296
.text:F8224296 loc_F8224296: ; CODE XREF: KavNtTerminateProcess+C6j
.text:F8224296 push eax
.text:F8224297 call sub_F82134D0
.text:F822429C mov ecx, [esp+5Ch+ProcessData.TargetProcessId]
.text:F82242A0 push ecx
.text:F82242A1 call sub_F8221F70
.text:F82242A6 mov edx, [esp+5Ch+ExitStatus]
.text:F82242AA push edx
.text:F82242AB push esi
.text:F82242AC call OrigNtTerminateProcess
.text:F82242B2 mov esi, eax
.text:F82242B4 lea eax, [esp+5Ch+ProcessData]
.text:F82242B8 push 1 ; int
.text:F82242BA push eax ; ProcessData
.text:F82242BB mov [esp+64h+var_4], esi
.text:F82242BF call KavCheckTerminateProcess
.text:F82242C4 mov eax, esi
.text:F82242C6 pop esi
.text:F82242C7 pop ebx
.text:F82242C8 add esp, 54h
.text:F82242CB retn 8
.text:F82242CE ; ---------------------------------------------------------------------------
.text:F82242CE
.text:F82242CE Ret_KavNtTerminateProcess: ; CODE XREF: KavNtTerminateProcess+16j
.text:F82242CE ; KavNtTerminateProcess+1Ej
.text:F82242CE mov ecx, [esp+5Ch+ExitStatus]
.text:F82242D2 push ecx
.text:F82242D3 push esi
.text:F82242D4 call OrigNtTerminateProcess
.text:F82242DA pop esi
.text:F82242DB pop ebx
.text:F82242DC add esp, 54h
.text:F82242DF retn 8
.text:F82242DF KavNtTerminateProcess endp
The whole purpose of this particular system service hook is "shady" as well.
The hook prevents certain KAV processes from being terminated, even by a
legitimate computer administrator - something that is once again typically
associated with malicious software such as rootkits rather than commercial
software applications. One possible explanation is to attempt to prevent
viruses from terminating the virus scanner processes itself, although one
wonders how much of a concern this would be if KAV's real-time scanning
mechanisms really do work as advertised.
Additionally, KAV appears to do some state tracking just before the process is
terminated with this system service hook. The proper way to do this would have
been through PsSetCreateProcessNotifyRoutine, a documented kernel function that
allows drivers to register a callback that is called on process creation and
process exit.
2.5. Patching non-exported, non-system-service kernel functions.
KAV's kernel patching is not limited to just system services, however. One of
the most dangerous hooks that KAV installs is one in the middle of the
nt!SwapContext function, which is neither exported nor a system service (and
thus has reliable mechanism to be detected by driver code, other than code
fingerprinting). nt!SwapContext is called by the kernel on every context
switch in order to perform some internal bookkeeping tasks.
Patching such a critical, non-exported kernel function with a mechanism as
unreliable as blind code fingerprinting is, in the author's opinion, not a
particularly good idea. To make matters worse, KAV actually modifies code in
the middle of nt!SwapContext instead of patching the start of the function, and
as such makes assumptions about the internal register and stack usage of this
kernel function.
kd> u nt!SwapContext
nt!SwapContext:
804db924 0ac9 or cl,cl
804db926 26c6462d02 mov byte ptr es:[esi+0x2d],0x2
804db92b 9c pushfd
804db92c 8b0b mov ecx,[ebx]
804db92e e9dd69d677 jmp klif!KavSwapContext (f8242310)
The unmodified nt!SwapContext has code that runs along the lines of this:
lkd> u nt!SwapContext
nt!SwapContext:
80540ab0 0ac9 or cl,cl
80540ab2 26c6462d02 mov byte ptr es:[esi+0x2d],0x2
80540ab7 9c pushfd
80540ab8 8b0b mov ecx,[ebx]
80540aba 83bb9409000000 cmp dword ptr [ebx+0x994],0x0
80540ac1 51 push ecx
80540ac2 0f8535010000 jne nt!SwapContext+0x14d (80540bfd)
80540ac8 833d0ca0558000 cmp dword ptr [nt!PPerfGlobalGroupMask (8055a00c)],0x0
This is an extremely dangerous patching operation to make, for several reasons:
1. nt!SwapContext is a *very* hot code path, as it is called on every single
context switch. Therefore, patching it at runtime without running a non-trivial
risk of bringing down the system is very difficult, especially on
multiprocessor systems. KAV attempts to solve the synchronization problems
relating to patching this function on uniprocessor systems by disabling
interrupts entirely, but this approach will not work reliably on
multiprocessor systems. KAV makes no attempt to address this problem on
multiprocessor systems and puts them at the risk of randomly failing on boot
during KAV's patching.
2. Reliably locating this function and making assumptions about the register
and stack usage (and instruction layout) across all released and future
Windows versions is a practical impossibility, and yet KAV attempts to do
just this. This puts KAV customers at the mercy of the next Windows update,
which may cause their systems to crash on boot because KAV's hooking code
makes an assumption that has been invalidated about the context-switching
process.
Additionally, in order to perform code patching on the kernel, KAV adjusts the
page protections of kernel code to be writable by altering PTE attributes
directly instead of using documented functions (which would have proper locking
semantics for accessing internal memory management structures).
KAV nt!SwapContext patching:
.text:F82264EA mov eax, 90909090h ; Build the code to be written to nt!SwapContext
.text:F82264EF mov [ebp+var_38], eax
.text:F82264F2 mov [ebp+var_34], eax
.text:F82264F5 mov [ebp+var_30], ax
.text:F82264F9 mov byte ptr [ebp+var_38], 0E9h
.text:F82264FD mov ecx, offset KavSwapContext
.text:F8226502 sub ecx, ebx
.text:F8226504 sub ecx, 5
.text:F8226507 mov [ebp+var_38+1], ecx
.text:F822650A mov ecx, [ebp+var_1C]
.text:F822650D lea edx, [ecx+ebx]
.text:F8226510 mov dword_F8228338, edx
.text:F8226516 mov esi, ebx
.text:F8226518 mov edi, offset unk_F8227DBC
.text:F822651D mov eax, ecx
.text:F822651F shr ecx, 2
.text:F8226522 rep movsd
.text:F8226524 mov ecx, eax
.text:F8226526 and ecx, 3
.text:F8226529 rep movsb
.text:F822652B lea ecx, [ebp+var_48] ; Make nt!SwapContext writable by directly accessing
.text:F822652B ; the PTEs.
.text:F822652E push ecx
.text:F822652F push 1
.text:F8226531 push ebx
.text:F8226532 call ModifyPteAttributes
.text:F8226537 test al, al
.text:F8226539 jz short loc_F8226588
.text:F822653B mov ecx, offset KavInternalSpinLock
.text:F8226540 call KavSpinLockAcquire ; Disable interrupts
.text:F8226545 mov ecx, [ebp+var_1C] ; Write to kernel code
.text:F8226548 lea esi, [ebp+var_38]
.text:F822654B mov edi, ebx
.text:F822654D mov edx, ecx
.text:F822654F shr ecx, 2
.text:F8226552 rep movsd
.text:F8226554 mov ecx, edx
.text:F8226556 and ecx, 3
.text:F8226559 rep movsb
.text:F822655B mov edx, eax
.text:F822655D mov ecx, offset KavInternalSpinLock
.text:F8226562 call KavSpinLockRelease ; Reenable interrupts
.text:F8226567 lea eax, [ebp+var_48] ; Restore the original PTE attributes.
.text:F822656A push eax
.text:F822656B mov ecx, [ebp+var_48]
.text:F822656E push ecx
.text:F822656F push ebx
.text:F8226570 call ModifyPteAttributes
.text:F8226575 mov al, 1
.text:F8226577 mov ecx, [ebp+var_10]
.text:F822657A mov large fs:0, ecx
.text:F8226581 pop edi
.text:F8226582 pop esi
.text:F8226583 pop ebx
.text:F8226584 mov esp, ebp
.text:F8226586 pop ebp
.text:F8226587 retn
KavSpinLockAcquire subroutine (disables interrupts):
.text:F8221240 KavSpinLockAcquire proc near ; CODE XREF: sub_F8225690+D7p
.text:F8221240 ; sub_F8225D50+8Cp ...
.text:F8221240 pushf
.text:F8221241 pop eax
.text:F8221242
.text:F8221242 loc_F8221242: ; CODE XREF: KavSpinLockAcquire+13j
.text:F8221242 cli
.text:F8221243 lock bts dword ptr [ecx], 0
.text:F8221248 jb short loc_F822124B
.text:F822124A retn
.text:F822124B ; ---------------------------------------------------------------------------
.text:F822124B
.text:F822124B loc_F822124B: ; CODE XREF: KavSpinLockAcquire+8j
.text:F822124B push eax
.text:F822124C popf
.text:F822124D
.text:F822124D loc_F822124D: ; CODE XREF: KavSpinLockAcquire+17j
.text:F822124D test dword ptr [ecx], 1
.text:F8221253 jz short loc_F8221242
.text:F8221255 pause
.text:F8221257 jmp short loc_F822124D
.text:F8221257 KavSpinLockAcquire endp
KavSpinLockRelease subroutine (reenables interrupts):
.text:F8221260 KavSpinLockRelease proc near ; CODE XREF: sub_F8225690+F2p
.text:F8221260 ; sub_F8225D50+BAp ...
.text:F8221260 mov dword ptr [ecx], 0
.text:F8221266 push edx
.text:F8221267 popf
.text:F8221268 retn
.text:F8221268 KavSpinLockRelease endp
ModifyPteAttributes subroutine:
.text:F82203C0 ModifyPteAttributes proc near ; CODE XREF: sub_F821A9D0+91p
.text:F82203C0 ; sub_F8220950+43p ...
.text:F82203C0
.text:F82203C0 var_24 = dword ptr -24h
.text:F82203C0 var_20 = byte ptr -20h
.text:F82203C0 var_1C = dword ptr -1Ch
.text:F82203C0 var_18 = dword ptr -18h
.text:F82203C0 var_10 = dword ptr -10h
.text:F82203C0 var_4 = dword ptr -4
.text:F82203C0 arg_0 = dword ptr 8
.text:F82203C0 arg_4 = byte ptr 0Ch
.text:F82203C0 arg_8 = dword ptr 10h
.text:F82203C0
.text:F82203C0 push ebp
.text:F82203C1 mov ebp, esp
.text:F82203C3 push 0FFFFFFFFh
.text:F82203C5 push offset dword_F8212180
.text:F82203CA push offset _except_handler3
.text:F82203CF mov eax, large fs:0
.text:F82203D5 push eax
.text:F82203D6 mov large fs:0, esp
.text:F82203DD sub esp, 14h
.text:F82203E0 push ebx
.text:F82203E1 push esi
.text:F82203E2 push edi
.text:F82203E3 mov [ebp+var_18], esp
.text:F82203E6 xor ebx, ebx
.text:F82203E8 mov [ebp+var_20], bl
.text:F82203EB mov esi, [ebp+arg_0]
.text:F82203EE mov ecx, esi
.text:F82203F0 call KavGetEflags
.text:F82203F5 push esi
.text:F82203F6 call KavGetPte ; This is a function pointer filled in at runtime,
.text:F82203F6 ; differing based on whether the system has PAE
.text:F82203F6 ; enabled or not.
.text:F82203FC mov edi, eax
.text:F82203FE mov [ebp+var_1C], edi
.text:F8220401 cmp edi, 0FFFFFFFFh
.text:F8220404 jz short loc_F8220458
.text:F8220406 mov [ebp+var_4], ebx
.text:F8220409 mov ecx, esi
.text:F822040B call KavGetEflags
.text:F8220410 mov eax, [edi]
.text:F8220412 test al, 1
.text:F8220414 jz short loc_F8220451
.text:F8220416 mov ecx, eax
.text:F8220418 mov [ebp+var_24], ecx
.text:F822041B cmp [ebp+arg_4], bl
.text:F822041E jz short loc_F8220429
.text:F8220420 mov eax, [ebp+var_1C]
.text:F8220423 lock or dword ptr [eax], 2
.text:F8220427 jmp short loc_F8220430
.text:F8220429 ; ---------------------------------------------------------------------------
.text:F8220429
.text:F8220429 loc_F8220429: ; CODE XREF: ModifyPteAttributes+5Ej
.text:F8220429 mov eax, [ebp+var_1C]
.text:F822042C lock and dword ptr [eax], 0FFFFFFFDh
.text:F8220430
.text:F8220430 loc_F8220430: ; CODE XREF: ModifyPteAttributes+67j
.text:F8220430 mov eax, [ebp+arg_8]
.text:F8220433 cmp eax, ebx
.text:F8220435 jz short loc_F822043C
.text:F8220437 and ecx, 2
.text:F822043A mov [eax], cl
.text:F822043C
.text:F822043C loc_F822043C: ; CODE XREF: ModifyPteAttributes+75j
.text:F822043C mov [ebp+var_20], 1
.text:F8220440 mov eax, [ebp+arg_0]
.text:F8220443 invlpg byte ptr [eax]
.text:F8220446 jmp short loc_F8220451
.text:F8220448 ; ---------------------------------------------------------------------------
.text:F8220448
.text:F8220448 loc_F8220448: ; DATA XREF: .text:F8212184o
.text:F8220448 mov eax, 1
.text:F822044D retn
.text:F822044E ; ---------------------------------------------------------------------------
.text:F822044E
.text:F822044E loc_F822044E: ; DATA XREF: .text:F8212188o
.text:F822044E mov esp, [ebp-18h]
.text:F8220451
.text:F8220451 loc_F8220451: ; CODE XREF: ModifyPteAttributes+54j
.text:F8220451 ; ModifyPteAttributes+86j
.text:F8220451 mov [ebp+var_4], 0FFFFFFFFh
.text:F8220458
.text:F8220458 loc_F8220458: ; CODE XREF: ModifyPteAttributes+44j
.text:F8220458 mov al, [ebp+var_20]
.text:F822045B mov ecx, [ebp+var_10]
.text:F822045E mov large fs:0, ecx
.text:F8220465 pop edi
.text:F8220466 pop esi
.text:F8220467 pop ebx
.text:F8220468 mov esp, ebp
.text:F822046A pop ebp
.text:F822046B retn 0Ch
.text:F822046B ModifyPteAttributes endp
2.6. Allowing user mode code to access kernel memory directly from user mode,
improper validation of user mode structures.
One of the most important principles of the kernel/user division that modern
operating systems enforce is that user mode is not allowed to directly access
kernel mode memory. This is necessary to enforce system stability, otherwise
a buggy user mode program could corrupt the kernel and bring down the whole
system.
Unfortunately, the KAV programmers appear to think that this distinction is not
really so important after all.
One of the strangest of the unsafe practicies implemented by KAV is to allow
user mode to directly call some portions of their kernel driver (within kernel
address space!) instead of just loading a user mode DLL (or otherwise loading
user mode code in the target process).
This mechanism appears to be used to inspect DLLs as they are loaded - a task
which would be much better accomplished with PsSetLoadImageNotifyRoutine.
KAV patches kernel32.dll as a new process is created, such that the export
table points all of the DLL-loading routines (e.g. LoadLibraryA) to a thunk
that calls portions of KAV's driver in kernel mode. Additionally, KAV modifes
protections on parts of its code and data sections to allow user mode read
access.
KAV sets a PsLoadImageNotifyRoutine hook to detect kernel32.dll being loaded in
order to know when to patch kernel32's export table. The author wonders why
KAV did not just do their work from within PsSetLoadImageNotifyRoutine directly
instead of going through all the trouble to allow user mode to call kernel mode
for a LoadLibrary hook.
The CheckInjectCodeForNewProcess function is called when a new process loads an
image, and checks for kernel32 being loaded. If this is the case, it will
queue an APC to the process that will perform patching.
.text:F82218B0 ; int __stdcall CheckInjectCodeForNewProcess(wchar_t *,PUCHAR ImageBase)
.text:F82218B0 CheckInjectCodeForNewProcess proc near ; CODE XREF: KavLoadImageNotifyRoutine+B5p
.text:F82218B0 ; KavDoKernel32Check+41p
.text:F82218B0
.text:F82218B0 arg_0 = dword ptr 4
.text:F82218B0 ImageBase = dword ptr 8
.text:F82218B0
.text:F82218B0 mov al, byte_F82282F9
.text:F82218B5 push esi
.text:F82218B6 test al, al
.text:F82218B8 push edi
.text:F82218B9 jz short loc_F8221936
.text:F82218BB mov eax, [esp+8+arg_0]
.text:F82218BF push offset aKernel32_dll ; "kernel32.dll"
.text:F82218C4 push eax ; wchar_t *
.text:F82218C5 call ds:_wcsicmp
.text:F82218CB add esp, 8
.text:F82218CE test eax, eax
.text:F82218D0 jnz short loc_F8221936
.text:F82218D2 mov al, g_FoundKernel32Exports
.text:F82218D7 mov edi, [esp+8+ImageBase]
.text:F82218DB test al, al
.text:F82218DD jnz short KavInitializePatchApcLabel
.text:F82218DF push edi
.text:F82218E0 call KavCheckFindKernel32Exports
.text:F82218E5 test al, al
.text:F82218E7 jz short loc_F8221936
.text:F82218E9
.text:F82218E9 KavInitializePatchApcLabel: ; CODE XREF: CheckInjectCodeForNewProcess+2Dj
.text:F82218E9 push '3SeB' ; Tag
.text:F82218EE push 30h ; NumberOfBytes
.text:F82218F0 push 0 ; PoolType
.text:F82218F2 call ds:ExAllocatePoolWithTag
.text:F82218F8 mov esi, eax
.text:F82218FA test esi, esi
.text:F82218FC jz short loc_F8221936
.text:F82218FE push edi
.text:F82218FF push 0
.text:F8221901 push offset KavPatchNewProcessApcRoutine
.text:F8221906 push offset loc_F82218A0
.text:F822190B push offset loc_F8221890
.text:F8221910 push 0
.text:F8221912 call KeGetCurrentThread
.text:F8221917 push eax
.text:F8221918 push esi
.text:F8221919 call KeInitializeApc
.text:F822191E push 0
.text:F8221920 push 0
.text:F8221922 push 0
.text:F8221924 push esi
.text:F8221925 call KeInsertQueueApc
.text:F822192B test al, al
.text:F822192D jnz short loc_F822193D
.text:F822192F push esi ; P
.text:F8221930 call ds:ExFreePool
.text:F8221936
.text:F8221936 loc_F8221936: ; CODE XREF: CheckInjectCodeForNewProcess+9j
.text:F8221936 ; CheckInjectCodeForNewProcess+20j ...
.text:F8221936 pop edi
.text:F8221937 xor al, al
.text:F8221939 pop esi
.text:F822193A retn 8
.text:F822193D ; ---------------------------------------------------------------------------
.text:F822193D
.text:F822193D loc_F822193D: ; CODE XREF: CheckInjectCodeForNewProcess+7Dj
.text:F822193D pop edi
.text:F822193E mov al, 1
.text:F8221940 pop esi
.text:F8221941 retn 8
The APC routine itself patches kernel32's export table (and generates the
thunks to call kernel mode) and adjusts PTE attributes on KAV's driver image
to allow user mode access.
.text:F8221810 KavPatchNewProcessApcRoutine proc near ; DATA XREF: CheckInjectCodeForNewProcess+51o
.text:F8221810
.text:F8221810 var_8 = dword ptr -8
.text:F8221810 var_4 = dword ptr -4
.text:F8221810 ImageBase = dword ptr 8
.text:F8221810
.text:F8221810 push ebp
.text:F8221811 mov ebp, esp
.text:F8221813 sub esp, 8
.text:F8221816 mov eax, [ebp+ImageBase]
.text:F8221819 push esi
.text:F822181A push eax ; ImageBase
.text:F822181B call KavPatchImageForNewProcess
.text:F8221820 mov esi, dword_F8230518
.text:F8221826 mov eax, dword_F823051C
.text:F822182B and esi, 0FFFFF000h
.text:F8221831 cmp esi, eax
.text:F8221833 mov [ebp+ImageBase], esi
.text:F8221836 jnb short loc_F8221883
.text:F8221838
.text:F8221838 loc_F8221838: ; CODE XREF: KavPatchNewProcessApcRoutine+71j
.text:F8221838 push esi
.text:F8221839 call KavPageTranslation0
.text:F822183F push esi
.text:F8221840 mov [ebp+var_8], eax
.text:F8221843 call KavPageTranslation1
.text:F8221849 mov [ebp+var_4], eax
.text:F822184C mov eax, [ebp+var_8]
.text:F822184F lock or dword ptr [eax], 4
.text:F8221853 lock and dword ptr [eax], 0FFFFFEFFh
.text:F822185A mov eax, [ebp+var_4]
.text:F822185D invlpg byte ptr [eax]
.text:F8221860 lock or dword ptr [eax], 4
.text:F8221864 lock and dword ptr [eax], 0FFFFFEFDh
.text:F822186B mov eax, [ebp+ImageBase]
.text:F822186E invlpg byte ptr [eax]
.text:F8221871 mov eax, dword_F823051C
.text:F8221876 add esi, 1000h
.text:F822187C cmp esi, eax
.text:F822187E mov [ebp+ImageBase], esi
.text:F8221881 jb short loc_F8221838
.text:F8221883
.text:F8221883 loc_F8221883: ; CODE XREF: KavPatchNewProcessApcRoutine+26j
.text:F8221883 pop esi
.text:F8221884 mov esp, ebp
.text:F8221886 pop ebp
.text:F8221887 retn 0Ch
.text:F8221887 KavPatchNewProcessApcRoutine endp
.text:F8221750 ; int __stdcall KavPatchImageForNewProcess(PUCHAR ImageBase)
.text:F8221750 KavPatchImageForNewProcess proc near ; CODE XREF: KavPatchNewProcessApcRoutine+Bp
.text:F8221750
.text:F8221750 ImageBase = dword ptr 8
.text:F8221750
.text:F8221750 push ebx
.text:F8221751 call ds:KeEnterCriticalRegion
.text:F8221757 mov eax, dword_F82282F4
.text:F822175C push 1 ; Wait
.text:F822175E push eax ; Resource
.text:F822175F call ds:ExAcquireResourceExclusiveLite
.text:F8221765 push 1
.text:F8221767 call KavSetPageAttributes1
.text:F822176C mov ecx, [esp+ImageBase]
.text:F8221770 push ecx ; ImageBase
.text:F8221771 call KavPatchImage
.text:F8221776 push 0
.text:F8221778 mov bl, al
.text:F822177A call KavSetPageAttributes1
.text:F822177F mov ecx, dword_F82282F4 ; Resource
.text:F8221785 call ds:ExReleaseResourceLite
.text:F822178B call ds:KeLeaveCriticalRegion
.text:F8221791 mov al, bl
.text:F8221793 pop ebx
.text:F8221794 retn 4
.text:F8221794 KavPatchImageForNewProcess endp
The actual image patching reprotects the export table of kernel32, changes the
export address table entries for the LoadLibrary* family of functions to point
to a thunk that is written into spare space within the kernel32 image, and
writes the actual thunk code out:
.text:F8221680 ; int __stdcall KavPatchImage(PUCHAR ImageBase)
.text:F8221680 KavPatchImage proc near ; CODE XREF: KavPatchImageForNewProcess+21p
.text:F8221680
.text:F8221680 var_C = dword ptr -0Ch
.text:F8221680 FunctionVa = dword ptr -8
.text:F8221680 var_4 = dword ptr -4
.text:F8221680 ImageBase = dword ptr 4
.text:F8221680
.text:F8221680 mov eax, [esp+ImageBase]
.text:F8221684 sub esp, 0Ch
.text:F8221687 push ebp
.text:F8221688 push 3Ch
.text:F822168A push eax
.text:F822168B call KavReprotectExportTable
.text:F8221690 mov ebp, eax
.text:F8221692 test ebp, ebp
.text:F8221694 jnz short loc_F822169F
.text:F8221696 xor al, al
.text:F8221698 pop ebp
.text:F8221699 add esp, 0Ch
.text:F822169C retn 4
.text:F822169F ; ---------------------------------------------------------------------------
.text:F822169F
.text:F822169F loc_F822169F: ; CODE XREF: KavPatchImage+14j
.text:F822169F push ebx
.text:F82216A0 push esi
.text:F82216A1 push edi
.text:F82216A2 xor ebx, ebx
.text:F82216A4 mov edi, ebp
.text:F82216A6 mov esi, offset ExportedFunctionsToCheckTable
.text:F82216AB
.text:F82216AB CheckNextFunctionInTable: ; CODE XREF: KavPatchImage+B4j
.text:F82216AB mov edx, [esi+0Ch]
.text:F82216AE mov eax, [esp+1Ch+ImageBase]
.text:F82216B2 lea ecx, [esp+1Ch+var_C]
.text:F82216B6 push ecx
.text:F82216B7 push edx
.text:F82216B8 push eax
.text:F82216B9 call LookupExportedFunction
.text:F82216BE test eax, eax
.text:F82216C0 mov [esp+1Ch+FunctionVa], eax
.text:F82216C4 jz short loc_F8221725
.text:F82216C6 mov edx, [esp+1Ch+var_C]
.text:F82216CA lea ecx, [esp+1Ch+var_4]
.text:F82216CE push ecx
.text:F82216CF push 40h
.text:F82216D1 push 4
.text:F82216D3 push edx
.text:F82216D4 call KavExecuteNtProtectVirtualMemoryInt2E
.text:F82216D9 test al, al
.text:F82216DB jz short loc_F8221725
.text:F82216DD cmp dword ptr [esi], 0
.text:F82216E0 jnz short loc_F82216EF
.text:F82216E2 mov eax, [esp+1Ch+FunctionVa]
.text:F82216E6 mov ecx, [esp+1Ch+var_C]
.text:F82216EA mov [esi], eax
.text:F82216EC mov [esi+8], ecx
.text:F82216EF
.text:F82216EF loc_F82216EF: ; CODE XREF: KavPatchImage+60j
.text:F82216EF mov eax, edi
.text:F82216F1 mov edx, 90909090h
.text:F82216F6 mov [eax], edx
.text:F82216F8 mov [eax+4], edx
.text:F82216FB mov [eax+8], edx
.text:F82216FE mov [eax+0Ch], dx
.text:F8221702 mov [eax+0Eh], dl
.text:F8221705 mov byte ptr [edi], 0E9h
.text:F8221708 mov ecx, [esi+4]
.text:F822170B mov edx, ebx
.text:F822170D sub ecx, ebx
.text:F822170F sub ecx, ebp
.text:F8221711 sub ecx, 5
.text:F8221714 mov [edi+1], ecx
.text:F8221717 mov ecx, [esp+1Ch+ImageBase]
.text:F822171B mov eax, [esp+1Ch+var_C]
.text:F822171F sub edx, ecx
.text:F8221721 add edx, ebp
.text:F8221723 mov [eax], edx ;
.text:F8221723 ; Patching Export Table here
.text:F8221723 ; e.g. write to 7c802f58
.text:F8221723 ; (kernel32 EAT entry for LoadLibraryA)
.text:F8221723 ;
.text:F8221723 ; 578 241 00001D77 LoadLibraryA = _LoadLibraryA@4
.text:F8221723 ; 579 242 00001D4F LoadLibraryExA = _LoadLibraryExA@12
.text:F8221723 ; 580 243 00001AF1 LoadLibraryExW = _LoadLibraryExW@12
.text:F8221723 ; 581 244 0000ACD3 LoadLibraryW = _LoadLibraryW@4
.text:F8221723 ;
.text:F8221723 ; KAV writes a new RVA pointing to its hook code here.
.text:F8221725
.text:F8221725 loc_F8221725: ; CODE XREF: KavPatchImage+44j
.text:F8221725 ; KavPatchImage+5Bj
.text:F8221725 add esi, 10h
.text:F8221728 add ebx, 0Fh
.text:F822172B add edi, 0Fh
.text:F822172E cmp esi, offset byte_F82357E0
.text:F8221734 jb CheckNextFunctionInTable
.text:F822173A pop edi
.text:F822173B pop esi
.text:F822173C pop ebx
.text:F822173D mov al, 1
.text:F822173F pop ebp
.text:F8221740 add esp, 0Ch
.text:F8221743 retn 4
.text:F8221743 KavPatchImage endp
KAV's export table reprotecting code assumes that the user mode PE header is
well-formed and does not contain offsets pointing to kernel mode addresses:
.text:F8221360 KavReprotectExportTable proc near ; CODE XREF: KavPatchImage+Bp
.text:F8221360
.text:F8221360 var_10 = dword ptr -10h
.text:F8221360 var_C = dword ptr -0Ch
.text:F8221360 var_8 = dword ptr -8
.text:F8221360 var_4 = dword ptr -4
.text:F8221360 arg_0 = dword ptr 4
.text:F8221360 arg_4 = dword ptr 8
.text:F8221360
.text:F8221360 mov eax, [esp+arg_0]
.text:F8221364 sub esp, 10h
.text:F8221367 cmp word ptr [eax], 'ZM'
.text:F822136C push ebx
.text:F822136D push ebp
.text:F822136E push esi
.text:F822136F push edi
.text:F8221370 jnz loc_F8221442
.text:F8221376 mov esi, [eax+3Ch]
.text:F8221379 add esi, eax
.text:F822137B mov [esp+20h+var_C], esi
.text:F822137F cmp dword ptr [esi], 'EP'
.text:F8221385 jnz loc_F8221442
.text:F822138B lea eax, [esp+20h+var_8]
.text:F822138F xor edx, edx
.text:F8221391 mov dx, [esi+14h]
.text:F8221395 push eax
.text:F8221396 xor eax, eax
.text:F8221398 push 40h
.text:F822139A mov ax, [esi+6]
.text:F822139E lea ecx, [eax+eax*4]
.text:F82213A1 lea eax, [edx+ecx*8+18h]
.text:F82213A5 push eax
.text:F82213A6 push esi
.text:F82213A7 call KavExecuteNtProtectVirtualMemoryInt2E ; NtProtectVirtualMemory
.text:F82213AC test al, al
.text:F82213AE jz loc_F8221442
.text:F82213B4 mov ecx, [esi+8]
.text:F82213B7 mov [esp+20h+var_10], 0
.text:F82213BF inc ecx
.text:F82213C0 mov [esi+8], ecx
.text:F82213C3 xor ecx, ecx
.text:F82213C5 mov cx, [esi+14h]
.text:F82213C9 cmp word ptr [esi+6], 0
.text:F82213CE lea edi, [ecx+esi+18h]
.text:F82213D2 jbe short loc_F8221442
.text:F82213D4 mov ebp, [esp+20h+arg_4]
.text:F82213D8
.text:F82213D8 loc_F82213D8: ; CODE XREF: KavReprotectExportTable+E0j
.text:F82213D8 mov ebx, [edi+10h]
.text:F82213DB test ebx, 0FFFh
.text:F82213E1 jz short loc_F82213EA
.text:F82213E3 or ebx, 0FFFh
.text:F82213E9 inc ebx
.text:F82213EA
.text:F82213EA loc_F82213EA: ; CODE XREF: KavReprotectExportTable+81j
.text:F82213EA mov ecx, [edi+8]
.text:F82213ED mov edx, ebx
.text:F82213EF sub edx, ecx
.text:F82213F1 cmp edx, ebp
.text:F82213F3 jle short loc_F822142C
.text:F82213F5 mov esi, [edi+0Ch]
.text:F82213F8 mov ecx, [esp+20h+arg_0]
.text:F82213FC sub esi, ebp
.text:F82213FE push ebp
.text:F82213FF add esi, ebx
.text:F8221401 add esi, ecx
.text:F8221403 push esi
.text:F8221404 call KavFindSectionName
.text:F8221409 test al, al
.text:F822140B jz short loc_F8221428
.text:F822140D cmp dword ptr [edi+1], 'TINI'
.text:F8221414 jz short loc_F8221428
.text:F8221416 lea eax, [esp+20h+var_4]
.text:F822141A push eax
.text:F822141B push 40h
.text:F822141D push ebp
.text:F822141E push esi
.text:F822141F call KavExecuteNtProtectVirtualMemoryInt2E ; NtProtectVirtualMemory
.text:F8221424 test al, al
.text:F8221426 jnz short loc_F822144E
.text:F8221428
.text:F8221428 loc_F8221428: ; CODE XREF: KavReprotectExportTable+ABj
.text:F8221428 ; KavReprotectExportTable+B4j
.text:F8221428 mov esi, [esp+20h+var_C]
.text:F822142C
.text:F822142C loc_F822142C: ; CODE XREF: KavReprotectExportTable+93j
.text:F822142C mov eax, [esp+20h+var_10]
.text:F8221430 xor ecx, ecx
.text:F8221432 mov cx, [esi+6]
.text:F8221436 add edi, 28h
.text:F8221439 inc eax
.text:F822143A cmp eax, ecx
.text:F822143C mov [esp+20h+var_10], eax
.text:F8221440 jb short loc_F82213D8
.text:F8221442
.text:F8221442 loc_F8221442: ; CODE XREF: KavReprotectExportTable+10j
.text:F8221442 ; KavReprotectExportTable+25j ...
.text:F8221442 pop edi
.text:F8221443 pop esi
.text:F8221444 pop ebp
.text:F8221445 xor eax, eax
.text:F8221447 pop ebx
.text:F8221448 add esp, 10h
.text:F822144B retn 8
.text:F822144E ; ---------------------------------------------------------------------------
.text:F822144E
.text:F822144E loc_F822144E: ; CODE XREF: KavReprotectExportTable+C6j
.text:F822144E mov eax, [edi+8]
.text:F8221451 mov [edi+10h], ebx
.text:F8221454 add eax, ebp
.text:F8221456 mov [edi+8], eax
.text:F8221459 mov eax, esi
.text:F822145B pop edi
.text:F822145C pop esi
.text:F822145D pop ebp
.text:F822145E pop ebx
.text:F822145F add esp, 10h
.text:F8221462 retn 8
.text:F8221462 KavReprotectExportTable endp
The mechanism by which KAV uses to reprotect user mode code is rather much of
a hack as well. KAV dynamically determines the system call ordinal of the
NtProtectVirtualMemory system service and uses its own int 2e thunk to call the
service.
.text:F8221320 KavExecuteNtProtectVirtualMemoryInt2E proc near
.text:F8221320 ; CODE XREF: KavReprotectExportTable+47p
.text:F8221320 ; KavReprotectExportTable+BFp ...
.text:F8221320
.text:F8221320 arg_0 = dword ptr 4
.text:F8221320 arg_4 = dword ptr 8
.text:F8221320 arg_8 = dword ptr 0Ch
.text:F8221320 arg_C = dword ptr 10h
.text:F8221320
.text:F8221320 mov eax, [esp+arg_0]
.text:F8221324 mov ecx, [esp+arg_C]
.text:F8221328 mov edx, [esp+arg_8]
.text:F822132C push ebx
.text:F822132D mov [esp+4+arg_0], eax
.text:F8221331 push ecx
.text:F8221332 lea eax, [esp+8+arg_4]
.text:F8221336 push edx
.text:F8221337 mov edx, NtProtectVirtualMemoryOrdinal
.text:F822133D lea ecx, [esp+0Ch+arg_0]
.text:F8221341 push eax
.text:F8221342 push ecx
.text:F8221343 push 0FFFFFFFFh
.text:F8221345 push edx
.text:F8221346 xor bl, bl
.text:F8221348 call KavInt2E
.text:F822134D test eax, eax
.text:F822134F mov al, 1
.text:F8221351 jge short loc_F8221355
.text:F8221353 mov al, bl
.text:F8221355
.text:F8221355 loc_F8221355: ; CODE XREF: KavExecuteNtProtectVirtualMemoryInt2E+31j
.text:F8221355 pop ebx
.text:F8221356 retn 10h
.text:F8221356 KavExecuteNtProtectVirtualMemoryInt2E endp
.user:F8231090 KavInt2E proc near ; CODE XREF: KavExecuteNtProtectVirtualMemoryInt2E+28p
.user:F8231090
.user:F8231090 arg_0 = dword ptr 8
.user:F8231090 arg_4 = dword ptr 0Ch
.user:F8231090
.user:F8231090 push ebp
.user:F8231091 mov ebp, esp
.user:F8231093 mov eax, [ebp+arg_0]
.user:F8231096 lea edx, [ebp+arg_4]
.user:F823109C int 2Eh
.user:F823109C
.user:F823109E pop ebp
.user:F823109F retn 18h
.user:F823109F KavInt2E endp
.user:F823109F
KAV's export lookup code does not correctly validate offsets garnered from the
PE header before using them:
.text:F8220CA0 LookupExportedFunction proc near ; CODE XREF: sub_F8217A60+C9p
.text:F8220CA0 ; sub_F82181D0+Dp ...
.text:F8220CA0
.text:F8220CA0 var_20 = dword ptr -20h
.text:F8220CA0 var_1C = dword ptr -1Ch
.text:F8220CA0 var_18 = dword ptr -18h
.text:F8220CA0 var_14 = dword ptr -14h
.text:F8220CA0 var_10 = dword ptr -10h
.text:F8220CA0 var_C = dword ptr -0Ch
.text:F8220CA0 var_8 = dword ptr -8
.text:F8220CA0 var_4 = dword ptr -4
.text:F8220CA0 arg_0 = dword ptr 4
.text:F8220CA0 arg_4 = dword ptr 8
.text:F8220CA0 arg_8 = dword ptr 0Ch
.text:F8220CA0
.text:F8220CA0 mov edx, [esp+arg_0]
.text:F8220CA4 sub esp, 20h
.text:F8220CA7 cmp word ptr [edx], 'ZM'
.text:F8220CAC push ebx
.text:F8220CAD push ebp
.text:F8220CAE push esi
.text:F8220CAF push edi
.text:F8220CB0 jnz loc_F8220DE1
.text:F8220CB6 mov eax, [edx+3Ch]
.text:F8220CB9 add eax, edx
.text:F8220CBB cmp dword ptr [eax], 'EP'
.text:F8220CC1 jnz loc_F8220DE1
.text:F8220CC7 mov eax, [eax+78h]
.text:F8220CCA mov edi, [esp+30h+arg_4]
.text:F8220CCE add eax, edx
.text:F8220CD0 mov [esp+30h+var_14], eax
.text:F8220CD4 mov esi, [eax+1Ch]
.text:F8220CD7 mov ebx, [eax+24h]
.text:F8220CDA mov ecx, [eax+20h]
.text:F8220CDD add esi, edx
.text:F8220CDF add ebx, edx
.text:F8220CE1 add ecx, edx
.text:F8220CE3 cmp edi, 1000h
.text:F8220CE9 mov [esp+30h+var_4], esi
.text:F8220CED mov [esp+30h+var_C], ebx
.text:F8220CF1 mov [esp+30h+var_18], ecx
.text:F8220CF5 jnb short loc_F8220D27
.text:F8220CF7 mov ecx, [eax+10h]
.text:F8220CFA mov eax, edi
.text:F8220CFC sub eax, ecx
.text:F8220CFE mov eax, [esi+eax*4]
.text:F8220D01 add eax, edx
.text:F8220D03 mov edx, [esp+30h+arg_8]
.text:F8220D07 test edx, edx
.text:F8220D09 jz loc_F8220DE3
.text:F8220D0F mov ebx, ecx
.text:F8220D11 shl ebx, 1Eh
.text:F8220D14 sub ebx, ecx
.text:F8220D16 add ebx, edi
.text:F8220D18 pop edi
.text:F8220D19 lea ecx, [esi+ebx*4]
.text:F8220D1C pop esi
.text:F8220D1D pop ebp
.text:F8220D1E mov [edx], ecx
.text:F8220D20 pop ebx
.text:F8220D21 add esp, 20h
.text:F8220D24 retn 0Ch
.text:F8220D27 ; ---------------------------------------------------------------------------
.text:F8220D27
.text:F8220D27 loc_F8220D27: ; CODE XREF: LookupExportedFunction+55j
.text:F8220D27 mov edi, [eax+14h]
.text:F8220D2A mov [esp+30h+arg_0], 0
.text:F8220D32 test edi, edi
.text:F8220D34 mov [esp+30h+var_8], edi
.text:F8220D38 jbe loc_F8220DE1
.text:F8220D3E mov [esp+30h+var_1C], esi
.text:F8220D42
.text:F8220D42 loc_F8220D42: ; CODE XREF: LookupExportedFunction+13Bj
.text:F8220D42 cmp dword ptr [esi], 0
.text:F8220D45 jz short loc_F8220DC5
.text:F8220D47 mov ecx, [eax+18h]
.text:F8220D4A xor ebp, ebp
.text:F8220D4C test ecx, ecx
.text:F8220D4E mov [esp+30h+var_10], ecx
.text:F8220D52 jbe short loc_F8220DC5
.text:F8220D54 mov edi, [esp+30h+var_18]
.text:F8220D58 mov [esp+30h+var_20], ebx
.text:F8220D5C
.text:F8220D5C loc_F8220D5C: ; CODE XREF: LookupExportedFunction+11Bj
.text:F8220D5C mov ebx, [esp+30h+var_20]
.text:F8220D60 xor esi, esi
.text:F8220D62 mov si, [ebx]
.text:F8220D65 mov ebx, [esp+30h+arg_0]
.text:F8220D69 cmp esi, ebx
.text:F8220D6B jnz short loc_F8220DAA
.text:F8220D6D mov eax, [edi]
.text:F8220D6F mov esi, [esp+30h+arg_4]
.text:F8220D73 add eax, edx
.text:F8220D75
.text:F8220D75 loc_F8220D75: ; CODE XREF: LookupExportedFunction+F3j
.text:F8220D75 mov bl, [eax]
.text:F8220D77 mov cl, bl
.text:F8220D79 cmp bl, [esi]
.text:F8220D7B jnz short loc_F8220D99
.text:F8220D7D test cl, cl
.text:F8220D7F jz short loc_F8220D95
.text:F8220D81 mov bl, [eax+1]
.text:F8220D84 mov cl, bl
.text:F8220D86 cmp bl, [esi+1]
.text:F8220D89 jnz short loc_F8220D99
.text:F8220D8B add eax, 2
.text:F8220D8E add esi, 2
.text:F8220D91 test cl, cl
.text:F8220D93 jnz short loc_F8220D75
.text:F8220D95
.text:F8220D95 loc_F8220D95: ; CODE XREF: LookupExportedFunction+DFj
.text:F8220D95 xor eax, eax
.text:F8220D97 jmp short loc_F8220D9E
.text:F8220D99 ; ---------------------------------------------------------------------------
.text:F8220D99
.text:F8220D99 loc_F8220D99: ; CODE XREF: LookupExportedFunction+DBj
.text:F8220D99 ; LookupExportedFunction+E9j
.text:F8220D99 sbb eax, eax
.text:F8220D9B sbb eax, 0FFFFFFFFh
.text:F8220D9E
.text:F8220D9E loc_F8220D9E: ; CODE XREF: LookupExportedFunction+F7j
.text:F8220D9E test eax, eax
.text:F8220DA0 jz short loc_F8220DED
.text:F8220DA2 mov eax, [esp+30h+var_14]
.text:F8220DA6 mov ecx, [esp+30h+var_10]
.text:F8220DAA
.text:F8220DAA loc_F8220DAA: ; CODE XREF: LookupExportedFunction+CBj
.text:F8220DAA mov esi, [esp+30h+var_20]
.text:F8220DAE inc ebp
.text:F8220DAF add esi, 2
.text:F8220DB2 add edi, 4
.text:F8220DB5 cmp ebp, ecx
.text:F8220DB7 mov [esp+30h+var_20], esi
.text:F8220DBB jb short loc_F8220D5C
.text:F8220DBD mov ebx, [esp+30h+var_C]
.text:F8220DC1 mov edi, [esp+30h+var_8]
.text:F8220DC5
.text:F8220DC5 loc_F8220DC5: ; CODE XREF: LookupExportedFunction+A5j
.text:F8220DC5 ; LookupExportedFunction+B2j
.text:F8220DC5 mov ecx, [esp+30h+arg_0]
.text:F8220DC9 mov esi, [esp+30h+var_1C]
.text:F8220DCD inc ecx
.text:F8220DCE add esi, 4
.text:F8220DD1 cmp ecx, edi
.text:F8220DD3 mov [esp+30h+arg_0], ecx
.text:F8220DD7 mov [esp+30h+var_1C], esi
.text:F8220DDB jb loc_F8220D42
.text:F8220DE1
.text:F8220DE1 loc_F8220DE1: ; CODE XREF: LookupExportedFunction+10j
.text:F8220DE1 ; LookupExportedFunction+21j ...
.text:F8220DE1 xor eax, eax
.text:F8220DE3
.text:F8220DE3 loc_F8220DE3: ; CODE XREF: LookupExportedFunction+69j
.text:F8220DE3 ; LookupExportedFunction+162j
.text:F8220DE3 pop edi
.text:F8220DE4 pop esi
.text:F8220DE5 pop ebp
.text:F8220DE6 pop ebx
.text:F8220DE7 add esp, 20h
.text:F8220DEA retn 0Ch
.text:F8220DED ; ---------------------------------------------------------------------------
.text:F8220DED
.text:F8220DED loc_F8220DED: ; CODE XREF: LookupExportedFunction+100j
.text:F8220DED mov eax, [esp+30h+var_4]
.text:F8220DF1 mov ecx, [esp+30h+arg_0]
.text:F8220DF5 lea ecx, [eax+ecx*4]
.text:F8220DF8 mov eax, [ecx]
.text:F8220DFA add eax, edx
.text:F8220DFC mov edx, [esp+30h+arg_8]
.text:F8220E00 test edx, edx
.text:F8220E02 jz short loc_F8220DE3
.text:F8220E04 pop edi
.text:F8220E05 pop esi
.text:F8220E06 pop ebp
.text:F8220E07 mov [edx], ecx
.text:F8220E09 pop ebx
.text:F8220E0A add esp, 20h
.text:F8220E0D retn 0Ch
.text:F8220E0D LookupExportedFunction endp
User mode calling KAV kernel code directly without a ring 0 transition:
kd> bp f824d820
kd> g
Breakpoint 0 hit
klif!sub_F8231820:
001b:f824d820 83ec08 sub esp,0x8
kd> kv
ChildEBP RetAddr Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
0006f4ec 7432f69c 74320000 00000001 00000000 klif!sub_F8231820
0006f50c 7c9011a7 74320000 00000001 00000000 0x7432f69c
0006f52c 7c91cbab 7432f659 74320000 00000001 ntdll!LdrpCallInitRoutine+0x14
0006f634 7c916178 00000000 c0150008 00000000 ntdll!LdrpRunInitializeRoutines+0x344 (FPO: [Non-Fpo])
0006f8e0 7c9162da 00000000 0007ced0 0006fbd4 ntdll!LdrpLoadDll+0x3e5 (FPO: [Non-Fpo])
0006fb88 7c801bb9 0007ced0 0006fbd4 0006fbb4 ntdll!LdrLoadDll+0x230 (FPO: [Non-Fpo])
0006fc20 f824d749 0106c0f0 0000000e 0107348c 0x7c801bb9
0006fd14 7c918dfa 7c90d625 7c90eacf 00000000 klif!loc_F823173D+0xc
0006fe00 7c910551 000712e8 00000044 0006ff0c ntdll!_LdrpInitialize+0x246 (FPO: [Non-Fpo])
0006fecc 00000000 00072368 00000000 00078c48 ntdll!RtlFreeHeap+0x1e9 (FPO: [Non-Fpo])
kd> t
klif!sub_F8231820+0x3:
001b:f824d823 53 push ebx
kd> r
eax=0006f3cc ebx=00000000 ecx=00005734 edx=0006f3ea esi=7c882fd3 edi=7432f608
eip=f824d823 esp=0006ef00 ebp=0006f4ec iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206
klif!sub_F8231820+0x3:
001b:f824d823 53 push ebx
kd> dg 1b
P Si Gr Pr Lo
Sel Base Limit Type l ze an es ng Flags
---- -------- -------- ---------- - -- -- -- -- --------
001B 00000000 ffffffff Code RE 3 Bg Pg P Nl 00000cfa
kd> !pte eip
VA f824d823
PDE at C0300F80 PTE at C03E0934
contains 01010067 contains 06B78065
pfn 1010 ---DA--UWEV pfn 6b78 ---DA--UREV
KAV crashing the system when stepping through its kernel mode code when called
from user mode (apparently not that reliable after all!):
Breakpoint 0 hit
klif!sub_F8231820:
001b:f824d820 83ec08 sub esp,0x8
kd> u eip
klif!sub_F8231820:
f824d820 ebfe jmp klif!sub_F8231820 (f824d820)
f824d822 085355 or [ebx+0x55],dl
f824d825 56 push esi
f824d826 57 push edi
f824d827 33ed xor ebp,ebp
f824d829 6820d824f8 push 0xf824d820
f824d82e 896c2418 mov [esp+0x18],ebp
f824d832 896c2414 mov [esp+0x14],ebp
kd> g
Breakpoint 0 hit
klif!sub_F8231820:
001b:f824d820 ebfe jmp klif!sub_F8231820 (f824d820)
kd> g
Breakpoint 0 hit
klif!sub_F8231820:
001b:f824d820 ebfe jmp klif!sub_F8231820 (f824d820)
kd> bd 0
kd> g
Break instruction exception - code 80000003 (first chance)
*******************************************************************************
* *
* You are seeing this message because you pressed either *
* CTRL+C (if you run kd.exe) or, *
* CTRL+BREAK (if you run WinDBG), *
* on your debugger machine's keyboard. *
* *
* THIS IS NOT A BUG OR A SYSTEM CRASH *
* *
* If you did not intend to break into the debugger, press the "g" key, then *
* press the "Enter" key now. This message might immediately reappear. If it *
* does, press "g" and "Enter" again. *
* *
*******************************************************************************
nt!RtlpBreakWithStatusInstruction:
804e3592 cc int 3
kd> gu
*** Fatal System Error: 0x000000d1
(0x00003592,0x0000001C,0x00000000,0x00003592)
Break instruction exception - code 80000003 (first chance)
*******************************************************************************
* *
* You are seeing this message because you pressed either *
* CTRL+C (if you run kd.exe) or, *
* CTRL+BREAK (if you run WinDBG), *
* on your debugger machine's keyboard. *
* *
* THIS IS NOT A BUG OR A SYSTEM CRASH *
* *
* If you did not intend to break into the debugger, press the "g" key, then *
* press the "Enter" key now. This message might immediately reappear. If it *
* does, press "g" and "Enter" again. *
* *
*******************************************************************************
nt!RtlpBreakWithStatusInstruction:
804e3592 cc int 3
kd> g
Break instruction exception - code 80000003 (first chance)
A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.
A fatal system error has occurred.
Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE
Loading Kernel Symbols
................................................................................................................
Loading User Symbols
................................
Loading unloaded module list
............
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck D1, {3592, 1c, 0, 3592}
*** ERROR: Module load completed but symbols could not be loaded for klif.sys
Probably caused by : hardware
Followup: MachineOwner
---------
*** Possible invalid call from 804e331f ( nt!KeUpdateSystemTime+0x160 )
*** Expected target 804e358e ( nt!DbgBreakPointWithStatus+0x0 )
nt!RtlpBreakWithStatusInstruction:
804e3592 cc int 3
kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 00003592, memory referenced
Arg2: 0000001c, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 00003592, address which referenced memory
Debugging Details:
------------------
READ_ADDRESS: 00003592
CURRENT_IRQL: 1c
FAULTING_IP:
+3592
00003592 ?? ???
PROCESS_NAME: winlogon.exe
DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO
BUGCHECK_STR: 0xD1
LAST_CONTROL_TRANSFER: from 804e3324 to 00003592
FAILED_INSTRUCTION_ADDRESS:
+3592
00003592 ?? ???
POSSIBLE_INVALID_CONTROL_TRANSFER: from 804e331f to 804e358e
TRAP_FRAME: f7872ce0 -- (.trap fffffffff7872ce0)
ErrCode = 00000000
eax=00000001 ebx=000275fc ecx=8055122c edx=000003f8 esi=00000005 edi=ddfff298
eip=00003592 esp=f7872d54 ebp=f7872d64 iopl=0 nv up ei pl nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202
00003592 ?? ???
Resetting default scope
STACK_TEXT:
WARNING: Frame IP not in any known module. Following frames may be wrong.
f7872d50 804e3324 00000001 f7872d00 000000d1 0x3592
f7872d50 f824d820 00000001 f7872d00 000000d1 nt!KeUpdateSystemTime+0x165
0006f4ec 7432f69c 74320000 00000001 00000000 klif+0x22820
0006f50c 7c9011a7 74320000 00000001 00000000 ODBC32!_DllMainCRTStartup+0x52
0006f52c 7c91cbab 7432f659 74320000 00000001 ntdll!LdrpCallInitRoutine+0x14
0006f634 7c916178 00000000 c0150008 00000000 ntdll!LdrpRunInitializeRoutines+0x344
0006f8e0 7c9162da 00000000 0007ced0 0006fbd4 ntdll!LdrpLoadDll+0x3e5
0006fb88 7c801bb9 0007ced0 0006fbd4 0006fbb4 ntdll!LdrLoadDll+0x230
0006fbf0 7c801d6e 7ffddc00 00000000 00000000 kernel32!LoadLibraryExW+0x18e
0006fc04 7c801da4 0106c0f0 00000000 00000000 kernel32!LoadLibraryExA+0x1f
0006fc20 f824d749 0106c0f0 0000000e 0107348c kernel32!LoadLibraryA+0x94
00000000 00000000 00000000 00000000 00000000 klif+0x22749
STACK_COMMAND: .trap 0xfffffffff7872ce0 ; kb
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: hardware
IMAGE_NAME: hardware
DEBUG_FLR_IMAGE_TIMESTAMP: 0
BUCKET_ID: CPU_CALL_ERROR
Followup: MachineOwner
---------
*** Possible invalid call from 804e331f ( nt!KeUpdateSystemTime+0x160 )
*** Expected target 804e358e ( nt!DbgBreakPointWithStatus+0x0 )
kd> u 804e331f
nt!KeUpdateSystemTime+0x160:
804e331f e86a020000 call nt!DbgBreakPointWithStatus (804e358e)
804e3324 ebb4 jmp nt!KeUpdateSystemTime+0x11b (804e32da)
804e3326 90 nop
804e3327 fb sti
804e3328 8d09 lea ecx,[ecx]
nt!KeUpdateRunTime:
804e332a a11cf0dfff mov eax,[ffdff01c]
804e332f 53 push ebx
804e3330 ff80c4050000 inc dword ptr [eax+0x5c4]
2.7. The solution.
KAV's anti-virus software relies upon many unsafe kernel-mode hacks that put
system stability in jeopardy. Removing unsafe kernel mode hacks like
patching non-exported kernel functions or hooking various system services
without parameter validation is the first step towards fixing the problem.
Many of the operations KAV uses hooking or other unsafe means for are doable
using documented and safe APIs and conventions that are well-described in the
Windows Device Driver Kit (DDK) and Installable File System Kit (IFS Kit). It
would behoove the KAV programmers to take the time to read and understand the
documented way to do things in the Windows kernel instead of taking a quite
literally hack-and-slash approach that leaves the system at risk of crashes
and potentially even privilege escalation.
Many of the unsafe practices relied upon by KAV are blocked by PatchGuard on
x64 and will make it significantly harder to release a 64-bit version of KAV's
anti-virus software (which will become increasingly important as computers are
sold with x64 support and run x64 Windows by default). Because 32-bit kernel
drivers cannot be loaded on 64-bit Windows, KAV will need to port their driver
to x64 and deal with PatchGuard. Additionally, assumptions that end user
computers will be uniprocessor are fast becoming obsolete, as most new systems
sold today support HyperThreading or multiple cores.
3. The problem: McAfee Internet Security Suite 2006
McAfee's Internet Security Suite 2006 package includes a number of programs,
including anti-virus, firewall, and anti-spam software. In particular,
however, this article discusses one particular facet of Internet Security Suite
2006: The McAfee Privacy Service.
This component is designed to intercept outbound traffic and sanitize it of any
predefined sensitive information before it hits the wire.
>From the very start, if one is familiar with network programming, such a goal
would appear to be very difficult to practically achieve. For instance, many
programs send data in a compressed or encrypted form, and there is no common
way to process such data without writing specialized software for each target
application. This immediately limits the effectiveness of the Privacy Service
software's generalized information sanitization process to programs that have
a) had specialized handler code written for them, or b) send information to
the Internet in plaintext. Furthermore, the very act of modifying an outbound
data stream could potentially cause an application to fail (consider the case
where an application network protocol includes its own checksums of data sent
and received, where arbitrary modifications of network traffic might cause it
to be rejected).
The problem with McAfee Internet Security Suite goes deeper, however. The
mechanism by which Internet Security Suite intercepts (and potentially alters)
outbound network traffic is through a Windows-specific mechanism known as an
LSP (or Layered Service Provider).
LSPs are user mode DLLs that "plug-in" to Winsock (the Windows sockets API) and
are called for every sockets API call that a user mode program makes. This
allows easy access to view (and modify) network traffic without going through
the complexities of writing a conventional kernel driver. An LSP is loaded and
called in the context of the program making the original socket API call.
This means that for most programs using user mode socket calls, all API calls
will be redirected through the Internet Security Suite's LSP, for potential
modification.
If one has been paying attention so far, this approach should already be
setting off alarms. One serious problem with this approach is that since the
LSP DLL itself resides in the same address space (and thus has the same
privileges) as the calling program, there is nothing technically stopping a
malicious program from modifying the LSP DLL's code to exempt itself from
alteration, or even bypassing the LSP directly.
Unfortunately, the flaws in the McAfee Privacy Service do not simply end here,
although already the technical limitations of an LSP for securely intercepting
and modifying network traffic make this approach (in the author's opinion)
wholly unsuitable for a program designed to protect a user from having his or
her private data stolen by malicious software.
Specifically, there are implementation flaws in how the LSP itself handles
certain socket API calls that may cause otherwise perfectly working software
to fail when run under McAfee Internet Security Suite 2006. This poses a
serious problem to software vendors, who are often forced to interoperate with
pervasive personal security software (such as Internet Security Suite).
The Windows Sockets environment is fully multithreaded and thread-safe, and
allows programs to call into the sockets API from multiple threads concurrently
without risk of data corruption or other instability. Unfortunately, the LSP
provided by McAfee for its Privacy Service software breaks this particular
portion of the Windows Sockets API contract. In particular, McAfee's LSP does
not correctly synchronize access to internal data structures when sockets are
created or destroyed, often leading to situations where a newly created socket
handed back to an application program is already mistakenly closed by the
flawed LSP before the application even sees it.
In addition, the author has also observed a similar synchronization problem
regarding the implementation of the `select' function in the Privacy Service
LSP. The select function is used to poll a set of sockets for a series of
events, such as data being available to read, or buffer space being available
to send data. The McAfee LSP appears to fail when calls to select are made
from multiple threads concurrently, however, often appearing to switch a
ocket handle specified by the original application program with an entirely
different handle. (In Windows, the same handle space is shared by
socket handles and all other types of kernel objects, such as files or
processes and threads). This subsequently results in calls to select failing
in strange ways, or worse, returning that data is available for a particular
socket when it was in fact available on a different socket entirely.
Both of these flaws result in intermittant failures of correctly written third
party applications when used in conjunction with McAfee Internet Security Suite
2006.
3.2. Solution for Software Vendors
If one is stuck in the unfortunate position of being forced to support software
running under McAfee Internet Security Suite 2006, one potential solution to
this problem is to manually serialize all calls to select (and other functions
that create or destroy sockets, such as socket and the WSASocket family of
functions). This approach has worked in practice, and is perhaps the least
invasive solution to the flawed LSP.
An alternative solution is to bypass the LSP entirely and instead call directly
to the kernel sockets driver (AFD.sys). However, this entails determining the
actual handle associated with a socket (the handle returned by the McAfee LSP
is in fact not the underlying socket handle), as well as relying on the as of
yet officially undocumented AFD IOCTL interface.
3.3. Solution for McAfee
>From McAfee's perspective, the solution is fairly simple: correctly serialize
access to internal data structures from function calls that are made from
multiple threads concurrently.
4. Conclusion
As the Internet becomes an increasingly hostile place and the need for in-depth
personal security software (as a supplement or even replacement for proper
system administrator) grows for end-users, it will become increasingly
important for the vendors and providers of personal security software to ensure
that their programs do not impair the normal operation of systems upon which
their software is installed. The author realizes that such is a very difficult
task given what is expected of most personal security software suites, and
hopes that by shedding light on the flaws in existing software, new programs
can be made to avoid similar mistakes.
