Local Privilege Escalation By Hijacking The VMwa

re VMX ProcessSun Bing

taoshaixiaoyao@hotmail.comCanSecWest

26th MAR 2008

Agenda VMware release notes and security advisories.

Vulnerabilities description.

Exploitation I (vmware.exe).

Exploitation II (vmware-authd.exe).

VMware internals (authd protocol,vmx86 ioctls,VMM).

Something about the newly released VMware versions.

Question time.

VMware 5.5.6 Release NotesNew in Version 5.5.6Workstation 5.5.6 addresses the following security issues: An internal security audit determined that a malicious user could attain and exploit Lo

calSystem privileges by causing the authd process to connect to a named pipe that is opened and controlled by the malicious user. In this situation, the malicious user could successfully impersonate authd and attain privileges under which Authd is executing. bug 221309, (Foundstone CODE-BUG-H-001)

This release updates the libpng library to version 1.2.22 to remove various security vulnerabilities.bug 224453

A vulnerability in VMware Workstation running on Windows allowed complete access to the host's file system from a guest machine. This access included the ability to create and modify executable files in sensitive locations.bug 224522, (CORE-2007-0930)

A security vulnerability in OpenSSL 0.9.7j could make it possible to forge a RSA key signature. Workstation 5.5.6 upgrades OpenSSL to version 0.9.7l to avoid this vulnerability. bug 236970), RSA Signature Forgery (CVE-2006-4339)

The authd process read and honored the vmx.fullpath variable in the user-writable file config.ini, creating a security vulnerability. bug 241646

The config.ini file could be modified by non-administrator to change the VMX launch path. This created a vulnerability that could be exploited to escalate a user's privileges. bug 241675

VMware Security Advisoriesh. Local Privilege Escalation on Windows based platforms by Hijacking VMware VMX configuration file VMware uses a configuration file named "config.ini" which is located in the application data directory of all users. By manipulating this file, a user could gain elevated privileges by hijacking the VMware VMX process. The Common Vulnerabilities and Exposures project (cve.mitre.org) assigned the name CVE-2008-1363 to this issue. Windows based Hosted products --------------- VMware Workstation 6.0 upgrade to version 6.0.3 (Build# 80004) VMware Workstation 5.5 upgrade to version 5.5.6 (Build# 80404) VMware Player 2.0 upgrade to version 2.0.3 (Build# 80004) VMware Player 1.0 upgrade to version 1.0.6 (Build# 80404) VMware Server 1.0 upgrade to version 1.0.5 (Build# 80187) VMware ACE 2.0 upgrade to version 2.0.1 (Build# 80004) VMware ACE 1.0 upgrade to version 1.0.5 (Build# 79846)

Vulnerability Description VMware uses an important configuration file named “config.ini”

which exists in the application data directory of all users, for example “C:\Documents and Settings\All Users\Application Data\VMware\VMware Workstation\config.ini”, which means even a common user (in Users group) can create(and modify) this config file.VMware locates this config file by using the Shell32 API “SHGetFolderPathA” with the 2nd argument nFolder being “CSIDL_FLAG_CREATE | CSIDL_COMMON_APPDATA”.

VMware determines the full path of VMX (vmware-vmx.exe) by two methods:

1. InstallPath value under “SOFTWARE\VMware, Inc.\VMware Workstation” registry key combined with “bin\vmware-vmx.exe”, which can’t be controlled by a common user.

2. “vmx.fullpath” config line within “config.ini”, which overrides the registry value above and can be controlled by a common user.

Therefore the consequence is that a common user can hijack the VMX process that will be launched by VMware by simply manipulating a config file, which then gives them chances to escalate their privileges.

VMware AppData Permissions (XP SP2)

Note: However in Windows 2000 and Vista, the Users group may not have write permission to the Application Data directory of all users by default.

Exploitation Method I The easiest exploitation method of this vulnerability is lik

e this: A low privileged user can add a config line (“vmx.fullpath”) within “config.ini” and point it to his/her fake VMX which is actually an exploitation program used to escalate privilege, then waits it to be launched later by a higher privileged VMware user. In some circumstances, all these exploitation actions (modifying the config file and uploading the fake VMX) could be performed remotely.

Demo: VMware.exe is trapped to launch a calc.exe (vmx.fullpath = c:\windows\system32\calc.exe, see the picture on the next page).

The shortcoming: What if no higher privileged user is gonna to use VMware in a short time, do we still need to keep on waiting?

VMX Hijacked

Exploitation Method II Another instantly effective exploitation method could b

e implemented via VMware Authorization Service (vmware-authd.exe) as follows:

1. The VMXExp adds a config line (“vmx.fullpath”) in “config.ini”, which points to itself.

2. The VMXExp sends the “vmexec” command to vmware-authd through a named pipe,and lets it launch itself.

3. The VMXExp gets executed by vmware-authd, although it still only runs at a lower privilege (authd uses ImpersonateLoggedOnUser and CreateProcessAsUserW), since it is now a child process of vmware-authd, it can ask authd to help opening any object which actually needs higher privilege (File/Device, Event, authd opens it and duplicates the handle to its child). The VMXExp sends the “opensecurable” command to vmware-authd through a named pipe, and asks it to open a file or device which can be used later to escalate privilege.

Exploitation Method II (Cont)4. The VMXExp reads the reply (prefixed with a “TOKEN” strin

g) from vmware-authd, and gets the duplicated handle to its desired file or device object.

5. The VMXExp can then continue with the real privilege escalation actions by using these handles. For example, a write mode handle to a critical Local System service executable image can be used to replace this service with a fake one, while a handle to VMware VMX86 device can be used to send some interesting IOCTLs (discussed later).

Demo: Local privilege escalation by system service replacement.

Note: Since vmware-authd of VMware 6.0 doesn’t look at the “vmx.fullpath” line in “config.ini” when creating the VMX process, this exploitation method can only be applied on VMware 5.5 (or below).

VMware Authd Protocols The Named Pipe used:

\\.\pipe\vmware-authdpipe

Commands supported: localconnect/tlocalconnect vmexec/vmexecdebug opensecurable:

“opensecurable”“objectname”|0x86b dwDesiredAccess dwShareMode dwCreationDisposition dwFlagsAndAttributes CurrentPID

openvmautomation

Except for the named pipe (for local use), VMware 6.0 authd also supports socket communication (VMware Authentication Daemon listens on the port 912), Some critical configurable items are still stored under all users’s profiles directory as the “config.ini”.

VMX86 Device IOCTLs Devie object exported by vmx86.sys:

\\.\vmx86

These Device I/O Control interfaces are protected, only higher privileged users can open the device handle and send IOCTLs (privileges must be higher than the “__vmware__” group, and the password of the only user “__vmware_user__” in this group seems to be generated randomly by VMware authd upon each startup), therefore firstly we need to bypass this protection by using the method introduced before.

Interesting VMX86 IOCTLs that facilitate arbitrary memory manipulation and ring0 code execution: IOCTL_VMX86_CREATE_VM, IOCTL_VMX86_INIT, IOCTL_VMX86_RUN_V

M: a fake crosspage,VMM and VM IOCTL_VMX86_LOOK_UP_MPN, IOCTL_VMX86_LOCK_PAGE, IOCTL_VMX

86_WRITE_PAGE …

Demo: Local privilege escalation by ring0 code execution.

Ring0 Code Execution Via VMX86 IOCTLs

IOCTL_VMX86_CREATE_VM: 0x81013f4c, out: VM id IOCTL_VMX86_INIT: 0x81013f5c, in: InitBlock IOCTL_VMX86_RUN_VM: 0x81013f67, in: VCPU id IOCTL_VMX86_RELEASE_VM: 0x81013f54

InitBlocktypedef struct _InitBlock_ {

DWORD MagicNumber; // INIT_BLOCK_MAGIC 0x1796DWORD UserCallHandle;DWORD NumVCPUs;void* CrossPage[MAX_INITBLOCK_CPUS]; // 32 slotsDWORD Iteration;

} InitBlock; CrossPage

size of 4K, and the Shell Code starts from offset 0x10, which will be executed by VMX86 in the kernel mode in the host world context (interrupts disabled but page table not switched)

VMware Virtual Machine Monitor

VMware VMM Core DumpIt resides within the VMware VMX (vmware-vmx.exe). Access the unimplemented devices regions (not emulated), such as the reserved IOAPIC registers, which would make VMM panic and to generate a core dump file for analyzing.

2 Isolated Worlds & 5 Different Contexts: Host World: Host Ring0, Host Ring3. Guest World: VMM(Ring0), Guest Ring0(Ring1), Guest Ring3.

VMware VMM security considerations: A parasitical Rootkits that hides within the VMware VMM, which g

ets executed at ring0 mode in both the Host and the Guest world. A possible way to run ring0 code without the need to load a drive

r, which can probably be used to bypass the driver signature verification in Windows Vista.

VMware Guest Context (VMM)<bochs:66> info cpueax:0x000c0370, ebx:0x77e29894, ecx:0x00000038, edx:0x000c0370ebp:0x00002f18, esp:0x00002ee8, esi:0x77e29894, edi:0x00002f40eip:0x00064d46, eflags:0x00080206, inhibit_mask:0cs:s=0x4020, dl=0x000003ff, dh=0xffc09ac0, valid=1ss:s=0x4028, dl=0x000003ff, dh=0xffc093c0, valid=7ds:s=0x4028, dl=0x000003ff, dh=0xffc093c0, valid=7es:s=0x4028, dl=0x000003ff, dh=0xffc093c0, valid=1fs:s=0x0000, dl=0x00000000, dh=0x00000000, valid=0gs:s=0x0000, dl=0x00000000, dh=0x00000000, valid=0ldtr:s=0x4060, dl=0xb0000000, dh=0xff0082ce, valid=1tr:s=0x4000, dl=0x64a00088, dh=0xff0089c0, valid=1gdtr:base=0xffc07000, limit=0x412fidtr:base=0xffc18000, limit=0x7ffdr0:0x00000000, dr1:0x00000000, dr2:0x00000000dr3:0x00000000, dr6:0xffff0ff0, dr7:0x00000700cr0:0x80010031, cr1:0x00000000, cr2:0x77e29894cr3:0x01e44020, cr4:0x00000635done

VMware Guest Context (Guest Ring0)

<bochs:52> info cpueax:0x00000000, ebx:0xe12490e8, ecx:0x00000000, edx:0x00000003ebp:0xbe4ef4a4, esp:0xbe4ef484, esi:0xe12490e0, edi:0x814a7428eip:0x0011ae11, eflags:0x00081246, inhibit_mask:0cs:s=0x4039, dl=0x000003ff, dh=0xffc0bbc0, valid=1ss:s=0x40d1, dl=0x0000fbff, dh=0x00cfb300, valid=7ds:s=0x0023, dl=0x0000fbff, dh=0x00cff300, valid=7es:s=0x0023, dl=0x0000fbff, dh=0x00cff300, valid=5fs:s=0x0030, dl=0xe0000001, dh=0xffc0b3ff, valid=7gs:s=0x4041, dl=0x000003ff, dh=0xffc0b3c0, valid=7ldtr:s=0x4060, dl=0xb0000000, dh=0xff0082ce, valid=1tr:s=0x4000, dl=0x64a00088, dh=0xff0089c0, valid=1gdtr:base=0xffc07000, limit=0x412fidtr:base=0xffc18000, limit=0x7ffdr0:0x00000000, dr1:0x00000000, dr2:0x00000000dr3:0x00000000, dr6:0xffff0ff0, dr7:0x00000700cr0:0x8001003b, cr1:0x00000000, cr2:0xe1ee8001cr3:0x01e44020, cr4:0x00000631done

VMware Guest Context (Guest Ring3)

<bochs:38> info cpueax:0x00e3f114, ebx:0x00000002, ecx:0x00e3ffdc, edx:0x00000001ebp:0x00e3eee0, esp:0x00e3ecc0, esi:0x00000000, edi:0x00000000eip:0x77c524a6, eflags:0x00080246, inhibit_mask:0cs:s=0x001b, dl=0x0000fbff, dh=0x00cffb00, valid=1ss:s=0x0023, dl=0x0000fbff, dh=0x00cff300, valid=7ds:s=0x0023, dl=0x0000fbff, dh=0x00cff300, valid=7es:s=0x0023, dl=0x0000fbff, dh=0x00cff300, valid=1fs:s=0x0038, dl=0x90000fff, dh=0x7f40f3fd, valid=7gs:s=0x0000, dl=0x00000000, dh=0x00000000, valid=0ldtr:s=0x4060, dl=0xb0000000, dh=0xff0082ce, valid=1tr:s=0x4000, dl=0x64a00088, dh=0xff0089c0, valid=1gdtr:base=0xffc07000, limit=0x412fidtr:base=0xffc18000, limit=0x7ffdr0:0x00000000, dr1:0x00000000, dr2:0x00000000dr3:0x00000000, dr6:0xffff0ff0, dr7:0x00000700cr0:0x8001003b, cr1:0x00000000, cr2:0x8003603acr3:0x01e44000, cr4:0x00000635done

VMware Guest Context (TSS)<bochs:40> info tsstr:s=0x4000, base=0xffc064a0, valid=1ss:esp(0): 0x4028:0x00002fe8ss:esp(1): 0x4041:0x00006000ss:esp(2): 0x4028:0x00002fe8cr3: 0x01e44020eip: 0x00055103eflags: 0x00000000cs: 0x4020 ds: 0x4028 ss: 0x4028es: 0x4028 fs: 0x0000 gs: 0x0000eax: 0x00006484 ebx: 0x000000d1 ecx: 0x81e45400 edx: 0x00006400esi: 0x00002f94 edi: 0x0000412f ebp: 0x00002f10 esp: 0x00002eb4ldt: 0x4060i/o map: 0x0088

VMware Guest Context (IDT)<bochs:34> info idtInterrupt Descriptor Table (base=0x00000000ffc18000, limit=2047):IDT[0x00]=32-Bit Interrupt Gate target=0x4020:0x00055536, DPL=0IDT[0x01]=32-Bit Interrupt Gate target=0x4020:0x0005554e, DPL=0IDT[0x02]=32-Bit Interrupt Gate target=0x4020:0x00018800, DPL=0IDT[0x03]=32-Bit Interrupt Gate target=0x4020:0x0005555b, DPL=1IDT[0x04]=32-Bit Interrupt Gate target=0x4020:0x00018810, DPL=0IDT[0x05]=32-Bit Interrupt Gate target=0x4020:0x00055568, DPL=0IDT[0x06]=32-Bit Interrupt Gate target=0x4020:0x00055580, DPL=0IDT[0x07]=32-Bit Interrupt Gate target=0x4020:0x0005558d, DPL=0IDT[0x08]=Task Gate target=0x4008:0x00000000, DPL=0IDT[0x09]=32-Bit Interrupt Gate target=0x4020:0x00018820, DPL=0…IDT[0xfb]=32-Bit Interrupt Gate target=0x4020:0x000c29c0, DPL=0IDT[0xfc]=32-Bit Interrupt Gate target=0x4020:0x000c29d0, DPL=0IDT[0xfd]=32-Bit Interrupt Gate target=0x4020:0x000c29e0, DPL=0IDT[0xfe]=32-Bit Interrupt Gate target=0x4020:0x000c29f0, DPL=0IDT[0xff]=32-Bit Interrupt Gate target=0x4020:0x000c2a00, DPL=0

VMware Guest Context (GDT)<bochs:43> info gdtGlobal Descriptor Table (base=0x00000000ffc07000, limit=16687):GDT[0x01]=Code segment, linearaddr=00000000, limit=ffbff * 4Kbytes, Execut

e/Read, Accessed, 32-bitGDT[0x02]=Data segment, linearaddr=00000000, limit=ffbff * 4Kbytes, Read/

WriteGDT[0x03]=Code segment, linearaddr=00000000, limit=ffbff * 4Kbytes, Execut

e/Read, Accessed, 32-bitGDT[0x04]=Data segment, linearaddr=00000000, limit=ffbff * 4Kbytes, Read/

Write, AccessedGDT[0x05]=32-Bit TSS (Busy) at 0x80285000, length 0x020abGDT[0x06]=Data segment, linearaddr=ffffe000, limit=00001 * 4Kbytes, Read/

Write, AccessedGDT[0x07]=Data segment, linearaddr=7ffd9000, limit=00fff bytes, Read/Write,

AccessedGDT[0x08]=Data segment, linearaddr=00000400, limit=0ffff bytes, Read/WriteGDT[0x0a]=32-Bit TSS (Available) at 0x80470040, length 0x00068GDT[0x0b]=32-Bit TSS (Available) at 0x804700a8, length 0x00068GDT[0x0c]=Data segment, linearaddr=00022ab0, limit=0ffff bytes, Read/Write…

VMware Guest Context (GDT Cont)GDT[0x800]=32-Bit TSS (Busy) at 0xffc064a0, length 0x00088GDT[0x801]=32-Bit TSS (Available) at 0xffcbe000, length 0x00067GDT[0x804]=Code segment, linearaddr=ffc00000, limit=003ff * 4Kbytes, Execut

e/Read, 32-bitGDT[0x805]=Data segment, linearaddr=ffc00000, limit=003ff * 4Kbytes, Read/

Write, AccessedGDT[0x806]=Data segment, linearaddr=ffc00000, limit=003ff * 4Kbytes, Read/

Write, AccessedGDT[0x807]=Code segment, linearaddr=ffc00000, limit=003ff * 4Kbytes, Execut

e/Read, Accessed, 32-bitGDT[0x808]=Data segment, linearaddr=ffc00000, limit=003ff * 4Kbytes, Read/

Write, AccessedGDT[0x809]=Data segment, linearaddr=00000000, limit=fffff * 4Kbytes, Read/W

rite, AccessedGDT[0x80a]=Code segment, linearaddr=81e45000, limit=00fff bytes, Execute/R

ead, 32-bitGDT[0x80b]=Code segment, linearaddr=ffc00000, limit=003ff * 4Kbytes, Execut

e/Read, 16-bitGDT[0x80c]=LDTGDT[0x80e]=Data segment, linearaddr=00000000, limit=ffbff * 4Kbytes, Read/

Write, Accessed…

Local Privilege Escalation Via VMX86

New Exploitation Method Is Game Over? Possibly Not!

Exploiting the newly released VMware versions (VMware Workstation 6.0.3 build 80004, 5.5.6 build 80404 etc) on almost all Windows platforms.

Demo: Local privilege escalation by exploiting the VMware Workstation 5.5.6 on Windows XP SP2.

Thanks For Watching ！Question & Discussion

Time