Local Privilege Escalation By Hijacking The VMware VMX Process

1
Local Privilege Escalation By Hijacking The
VMware VMX Process

• Sun Bing
• taoshaixiaoyao_at_hotmail.com
• CanSecWest
• 26th MAR 2008

2
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.

3
VMware 5.5.6 Release Notes

• New in Version 5.5.6
• Workstation 5.5.6 addresses the following
  security issues
• An internal security audit determined that a
  malicious user could attain and exploit
  LocalSystem 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

4
VMware Security Advisories

• h. 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)

5
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
• InstallPath value under SOFTWARE\VMware,
  Inc.\VMware Workstation registry key combined
  with bin\vmware-vmx.exe, which cant be
  controlled by a common user.
• 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.

6
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.
7
Exploitation Method I

• The easiest exploitation method of this
  vulnerability is like 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?

8
VMX Hijacked
9
Exploitation Method II

• Another instantly effective exploitation method
  could be implemented via VMware Authorization
  Service (vmware-authd.exe) as follows
• The VMXExp adds a config line (vmx.fullpath) in
  config.ini, which points to itself.
• The VMXExp sends the vmexec command to
  vmware-authd through a named pipe,and lets it
  launch itself.
• 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.

10
Exploitation Method II (Cont)

• The VMXExp reads the reply (prefixed with a
  TOKEN string) from vmware-authd, and gets the
  duplicated handle to its desired file or device
  object.
• 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 doesnt
  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).

11
VMware Authd Protocols

• The Named Pipe used
• \\.\pipe\vmware-authdpipe
• Commands supported
• localconnect/tlocalconnect
• vmexec/vmexecdebug
• opensecurable
• opensecurableobjectname0x86b
  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 userss profiles directory as
  the config.ini.

12
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_VM a fake crosspage,VMM and VM
• IOCTL_VMX86_LOOK_UP_MPN, IOCTL_VMX86_LOCK_PAGE,
  IOCTL_VMX86_WRITE_PAGE
• Demo Local privilege escalation by ring0 code
  execution.

13
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
• InitBlock
• typedef struct _InitBlock_
• DWORD MagicNumber // INIT_BLOCK_MAGIC 0x1796
• DWORD UserCallHandle
• DWORD NumVCPUs
• void CrossPageMAX_INITBLOCK_CPUS // 32 slots
• DWORD 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)

14
VMware Virtual Machine Monitor

• VMware VMM Core Dump
• It 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 gets 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 driver, which can probably be used to
  bypass the driver signature verification in
  Windows Vista.

15
VMware Guest Context (VMM)

• ltbochs66gt info cpu
• eax0x000c0370, ebx0x77e29894, ecx0x00000038,
  edx0x000c0370
• ebp0x00002f18, esp0x00002ee8, esi0x77e29894,
  edi0x00002f40
• eip0x00064d46, eflags0x00080206, inhibit_mask0
• css0x4020, dl0x000003ff, dh0xffc09ac0,
  valid1
• sss0x4028, dl0x000003ff, dh0xffc093c0,
  valid7
• dss0x4028, dl0x000003ff, dh0xffc093c0,
  valid7
• ess0x4028, dl0x000003ff, dh0xffc093c0,
  valid1
• fss0x0000, dl0x00000000, dh0x00000000,
  valid0
• gss0x0000, dl0x00000000, dh0x00000000,
  valid0
• ldtrs0x4060, dl0xb0000000, dh0xff0082ce,
  valid1
• trs0x4000, dl0x64a00088, dh0xff0089c0,
  valid1
• gdtrbase0xffc07000, limit0x412f
• idtrbase0xffc18000, limit0x7ff
• dr00x00000000, dr10x00000000, dr20x00000000
• dr30x00000000, dr60xffff0ff0, dr70x00000700
• cr00x80010031, cr10x00000000, cr20x77e29894
• cr30x01e44020, cr40x00000635
• done

16
VMware Guest Context (Guest Ring0)

• ltbochs52gt info cpu
• eax0x00000000, ebx0xe12490e8, ecx0x00000000,
  edx0x00000003
• ebp0xbe4ef4a4, esp0xbe4ef484, esi0xe12490e0,
  edi0x814a7428
• eip0x0011ae11, eflags0x00081246, inhibit_mask0
• css0x4039, dl0x000003ff, dh0xffc0bbc0,
  valid1
• sss0x40d1, dl0x0000fbff, dh0x00cfb300,
  valid7
• dss0x0023, dl0x0000fbff, dh0x00cff300,
  valid7
• ess0x0023, dl0x0000fbff, dh0x00cff300,
  valid5
• fss0x0030, dl0xe0000001, dh0xffc0b3ff,
  valid7
• gss0x4041, dl0x000003ff, dh0xffc0b3c0,
  valid7
• ldtrs0x4060, dl0xb0000000, dh0xff0082ce,
  valid1
• trs0x4000, dl0x64a00088, dh0xff0089c0,
  valid1
• gdtrbase0xffc07000, limit0x412f
• idtrbase0xffc18000, limit0x7ff
• dr00x00000000, dr10x00000000, dr20x00000000
• dr30x00000000, dr60xffff0ff0, dr70x00000700
• cr00x8001003b, cr10x00000000, cr20xe1ee8001
• cr30x01e44020, cr40x00000631
• done

17
VMware Guest Context (Guest Ring3)

• ltbochs38gt info cpu
• eax0x00e3f114, ebx0x00000002, ecx0x00e3ffdc,
  edx0x00000001
• ebp0x00e3eee0, esp0x00e3ecc0, esi0x00000000,
  edi0x00000000
• eip0x77c524a6, eflags0x00080246, inhibit_mask0
• css0x001b, dl0x0000fbff, dh0x00cffb00,
  valid1
• sss0x0023, dl0x0000fbff, dh0x00cff300,
  valid7
• dss0x0023, dl0x0000fbff, dh0x00cff300,
  valid7
• ess0x0023, dl0x0000fbff, dh0x00cff300,
  valid1
• fss0x0038, dl0x90000fff, dh0x7f40f3fd,
  valid7
• gss0x0000, dl0x00000000, dh0x00000000,
  valid0
• ldtrs0x4060, dl0xb0000000, dh0xff0082ce,
  valid1
• trs0x4000, dl0x64a00088, dh0xff0089c0,
  valid1
• gdtrbase0xffc07000, limit0x412f
• idtrbase0xffc18000, limit0x7ff
• dr00x00000000, dr10x00000000, dr20x00000000
• dr30x00000000, dr60xffff0ff0, dr70x00000700
• cr00x8001003b, cr10x00000000, cr20x8003603a
• cr30x01e44000, cr40x00000635
• done

18
VMware Guest Context (TSS)

• ltbochs40gt info tss
• trs0x4000, base0xffc064a0, valid1
• ssesp(0) 0x40280x00002fe8
• ssesp(1) 0x40410x00006000
• ssesp(2) 0x40280x00002fe8
• cr3 0x01e44020
• eip 0x00055103
• eflags 0x00000000
• cs 0x4020 ds 0x4028 ss 0x4028
• es 0x4028 fs 0x0000 gs 0x0000
• eax 0x00006484 ebx 0x000000d1 ecx 0x81e45400
  edx 0x00006400
• esi 0x00002f94 edi 0x0000412f ebp 0x00002f10
  esp 0x00002eb4
• ldt 0x4060
• i/o map 0x0088

19
VMware Guest Context (IDT)

• ltbochs34gt info idt
• Interrupt Descriptor Table (base0x00000000ffc1800
  0, limit2047)
• IDT0x0032-Bit Interrupt Gate
  target0x40200x00055536, DPL0
• IDT0x0132-Bit Interrupt Gate
  target0x40200x0005554e, DPL0
• IDT0x0232-Bit Interrupt Gate
  target0x40200x00018800, DPL0
• IDT0x0332-Bit Interrupt Gate
  target0x40200x0005555b, DPL1
• IDT0x0432-Bit Interrupt Gate
  target0x40200x00018810, DPL0
• IDT0x0532-Bit Interrupt Gate
  target0x40200x00055568, DPL0
• IDT0x0632-Bit Interrupt Gate
  target0x40200x00055580, DPL0
• IDT0x0732-Bit Interrupt Gate
  target0x40200x0005558d, DPL0
• IDT0x08Task Gate target0x40080x00000000,
  DPL0
• IDT0x0932-Bit Interrupt Gate
  target0x40200x00018820, DPL0
• IDT0xfb32-Bit Interrupt Gate
  target0x40200x000c29c0, DPL0
• IDT0xfc32-Bit Interrupt Gate
  target0x40200x000c29d0, DPL0
• IDT0xfd32-Bit Interrupt Gate
  target0x40200x000c29e0, DPL0
• IDT0xfe32-Bit Interrupt Gate
  target0x40200x000c29f0, DPL0
• IDT0xff32-Bit Interrupt Gate
  target0x40200x000c2a00, DPL0

20
VMware Guest Context (GDT)

• ltbochs43gt info gdt
• Global Descriptor Table (base0x00000000ffc07000,
  limit16687)
• GDT0x01Code segment, linearaddr00000000,
  limitffbff 4Kbytes, Execute/Read, Accessed,
  32-bit
• GDT0x02Data segment, linearaddr00000000,
  limitffbff 4Kbytes, Read/Write
• GDT0x03Code segment, linearaddr00000000,
  limitffbff 4Kbytes, Execute/Read, Accessed,
  32-bit
• GDT0x04Data segment, linearaddr00000000,
  limitffbff 4Kbytes, Read/Write, Accessed
• GDT0x0532-Bit TSS (Busy) at 0x80285000, length
  0x020ab
• GDT0x06Data segment, linearaddrffffe000,
  limit00001 4Kbytes, Read/Write, Accessed
• GDT0x07Data segment, linearaddr7ffd9000,
  limit00fff bytes, Read/Write, Accessed
• GDT0x08Data segment, linearaddr00000400,
  limit0ffff bytes, Read/Write
• GDT0x0a32-Bit TSS (Available) at 0x80470040,
  length 0x00068
• GDT0x0b32-Bit TSS (Available) at 0x804700a8,
  length 0x00068
• GDT0x0cData segment, linearaddr00022ab0,
  limit0ffff bytes, Read/Write

21
VMware Guest Context (GDT Cont)

• GDT0x80032-Bit TSS (Busy) at 0xffc064a0,
  length 0x00088
• GDT0x80132-Bit TSS (Available) at 0xffcbe000,
  length 0x00067
• GDT0x804Code segment, linearaddrffc00000,
  limit003ff 4Kbytes, Execute/Read, 32-bit
• GDT0x805Data segment, linearaddrffc00000,
  limit003ff 4Kbytes, Read/Write, Accessed
• GDT0x806Data segment, linearaddrffc00000,
  limit003ff 4Kbytes, Read/Write, Accessed
• GDT0x807Code segment, linearaddrffc00000,
  limit003ff 4Kbytes, Execute/Read, Accessed,
  32-bit
• GDT0x808Data segment, linearaddrffc00000,
  limit003ff 4Kbytes, Read/Write, Accessed
• GDT0x809Data segment, linearaddr00000000,
  limitfffff 4Kbytes, Read/Write, Accessed
• GDT0x80aCode segment, linearaddr81e45000,
  limit00fff bytes, Execute/Read, 32-bit
• GDT0x80bCode segment, linearaddrffc00000,
  limit003ff 4Kbytes, Execute/Read, 16-bit
• GDT0x80cLDT
• GDT0x80eData segment, linearaddr00000000,
  limitffbff 4Kbytes, Read/Write, Accessed

22
Local Privilege Escalation Via VMX86
23
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.

24

• Thanks For Watching!Question Discussion Time