Tuesday, August 12, 2008

Reliable code execution with TKADV2008-006

The CA HIPS kernel driver vulnerability described in TKADV2008-006 can be exploited using the common kernel pool (heap) write4 primitive. It is therefore possible to get reliable code execution in kernel mode under all supported plattforms (Windows 2000, XP and 2003).

An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high. This is caused by drivers that have corrupted the system pool. Run the driver verifier against any new (or suspect) drivers, and if that doesn't turn up the culprit, then use gflags to enable special pool.

Arg1: 41414141, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: 80543a03, address which referenced memory


80543a03 8913 mov dword ptr [ebx],edx


PROCESS_NAME: poc_xp.exe

TRAP_FRAME: f5c7faa0 -- (.trap 0xfffffffff5c7faa0)
ErrCode = 00000002
eax=0012df50 ebx=41414141 ecx=0012e050 edx=42424242 esi=81e44938 edi=000001ff eip=80543a03 esp=f5c7fb14 ebp=f5c7fb54 iopl=0 nv up ei ng nz ac pe cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010297
80543a03 8913 mov dword ptr [ebx],edx ds:0023:41414141=????????
Resetting default scope

LAST_CONTROL_TRANSFER: from 804f79d7 to 80526fc8

[...] 00000003 f5c7f9b0 00000000 nt!RtlpBreakWithStatusInstruction
[...] 00000003 41414141 80543a03 nt!KiBugCheckDebugBreak+0x19
[...] 0000000a 41414141 00000002 nt!KeBugCheck2+0x574
[...] 0000000a 41414141 00000002 nt!KiTrap0E+0x233
[...] 0012df58 00000000 0012ef70 nt!ExDeferredFreePool+0xfd
[...] 0012ef70 00000000 0012ef70 nt!ExFreePoolWithTag+0x489
[...] 0012ef70 81b81770 f6c87a01 nt!IoFreeMdl+0x6e
WARNING: Stack unwind information not available. Following frames may be wrong.
[...] 00000000 00000000 00000000 kmxfw+0x2b90

Thursday, August 07, 2008

A crude way to detect VMware

Yesterday the kernel maintainers fixed an information disclosure vulnerability I found in the Linux kernel a few days ago (see TKADV2008-2005). One interesting thing about the vulnerability is that it can be used to detect if a system is running as a guest inside VMware.

The vulnerability itself allows an unprivileged user to access and read arbitrary memory addresses including memory pages owned by the kernel. As I did some tests to check if the vulnerability is indeed exploitable I encountered a weird VMware problem: every time a special kernel memory range is accessed, VMware crashes reproducible.

That means that every similiar kernel bug that allows to read arbitrary kernel memory can be used to crash and therefore detect VMware as an unprivileged user.

With superuser privileges it is of course possible to reproduce the VMware crash without the need of a kernel vulnerability. All you have to do is write and load a kernel module that sweeps over the kernel memory space.