VMware High-Bandwidth Backdoor ROM Overwrite Privilege Elevation
securityfocus.com
securityfocus.com
* VMWare: most popular commercial OS virtualization product.
* Host: the VMWare hypervisor
* Guest: in this case, Windows Vista running under VMWare.
* VMWare backdoor interface: part of the feature that enables "VMWare Tools" to work, VMWare Tools being a set of features that make guest OS's more pleasant to use by making the host and guest communicate with each other.
* I/O instructions: the programmed IO features of the X86 ISA, nominally used by programs (usually the kernel) to communicate with peripherals. (The other common way of doing peripheral I/O is via memory mapping).
* CX, registers: the X86 ISA registers (CX is the 16-bit half of the 32-bit ECX register; EAX, ECX, EDX, and EBX are the primary X86 general-purpose registers with which X86 programs do virtually all their work).
* I/O port: the old addressing space for X86 peripherals.
* REP INSB: the bulk data version of "copy byte from I/O port to memory". Copies a count of bytes (in the ECX register) from the I/O port in the 16-bit DX register to the memory address specified in the EDI register.
* "High-bandwidth backdoor": a magic I/O port VMWare emulates in order to communicate between host and guest as if the host were a peripheral.
* Direction flag: The DF bit in the FLAGS register, determines whether bulk copy instruction sequences copy forwards or backwards; here, means "in the common case, VMWare pretends to do a REP INSB by having the host just call memcpy".
* Virtual DOS Mode (NTVDM or VDM): Windows' own built-in emulation of 16-bit DOS environments for programs not designed to work in 32 bit virtual address mode.
* ring-0, ring-3: kernel or userland, respectively.
* BIOS: The vestigial built-in firmware interface used in booting Windows on mainstream X86 hardware and, in the 1980s, as the "kernel" to which DOS programs (which had direct access to hardware) were programmed. Highly relevant in NTVDM, not so relevant to WinAPI programmers. BIOS ROM is, obviously, supposed to be read-only.
* NT!Whatever: Notation for C library function references: here, NTDLL.DLL the library, and "Whatever" the function. So, NT!VdmpInitialize is NTDLL's VdmpInitialize() function, which sets up memory for NTVDM environments launched by Windows. How does Derek know about this? Because all this stuff has been painstakingly reverse engineered over the last 15 years.
* INT instruction: generates a software interrupt, transferring control to the kernel's low-level interrupt handler.
* Interrupt vector table (IVT): An array of addresses of functions to be called to handle numbered interrupts. If you can overwrite any part of the IVT, you can cause the OS to unexpectedly redirect code somewhere else; that's an older Soeder NTVDM exploit, but not this one.
* INT 10h: the console video services interrupt, nominally handled by the BIOS. If you can overwrite the BIOS and have INT 10h generated, you can get control transfered to code you control. That's why the advisory keeps talking about hibernation and blue screen, both of which use BIOS video services (ie, classic DOS console video).
* HAL or HAL.DLL: the bottom edge of Windows hardware support, wraps & abstracts actual hardware. Somewhat equivalent to arch/i386/ in a Unix kernel.
* Real mode: the "nobody's ever going to need more than 64k of memory" mode in which 80's DOS programs expect to run, includes segmented memory and IN/OUT I/O instruction access. Emulated in NTVDM.
* TIB: Thread information block, the thread context, includes address space info. Remember that on Windows a process is basically a container of threads; an NTVDM process contains a VDM thread. An older Tavis Ormandy exploit targeted related memory ranges to forge trap frames so that when interrupt handlers "returned" in the kernel for NTVDM processes, they'd land in attacker-controlled code.
* Kernel stack pointer: part of the thread context, stores the current "position" of code in memory (for call/return... probably not going to bother explaining call stacks).
* info-set and info-get, VMdb guestinfo: akin to a config registry for VMware, a key-value store of ASCII strings.
FTFY.
Search forward to "six-stage approach" (!) for I think my favorite graf from any advisory written in the last 10 years.
(To understand it, know that the bug, distilled as far as I can distill it, is that a hypervisor-to-guest messaging layer in VMWare will overwrite BIOS memory that WinAPI and specifically the NT Virtual DOS mode in WinAPI assumes is read-only; VMWare's emulation is imperfect in that it will allow its message layer to write to those memory regions and thus corrupt the BIOS... BUT, you can only write data that's already resident in the hypervisor, and the only way the guest can "seed" hypervisor memory is through a channel that deals in ASCII.)
I found the underlying exploit here to be uncannily similar, designwise, to the Android jailbreak exploits in the INFILTRATE Android security slides that Immunity gave. "Oops, we allowed Dalvik processes to map read-write memory shared by init and the property database!"
(Understanding how Soeder could have discovered the flaw doesn't mean I think I stood a chance of putting this together).
I also think there's a fair bit of research done on the hypervisor/guest comms in VMWare. Also, Soeder appears to have taken up permanent residence in NTVDM. They should call it Soeder mode.
They probably found it a good idea to just reuse the code on Win7/32bit as well, so there goes the hole (a really good idea, I might add).
As for "writable ROM", some VGABIOSes map MMIO registers into the ROM area, as this is the only place safe for them to repurpose like this (16bit code, no real API for MMIO setup). I had coreboot's BIOS/x86 emulator (also used to run VGABIOS) break badly when I disabled those, and Microsoft has a much better test suite for issues like these.
* Web app vulnerabilities in the control plane (management tools, monitoring, API).
* Cryptographic vulnerabilities stemming from crypto code running on the same hardware as malicious attackers, or within nanoseconds-precision measurement range on the same network.
Cloud computing certainly opens up a plethora of side channel attacks that probably would not have been possible before.
[1] Its unfortunate that this is such a loosely defined term. I am not trying to be fussy and overly pedantic.
The side channel prediction is really interesting.(1) Do you think that capability will become widely dispersed or only the realm of the Advanced Persistent Attacker (or whatever the buzznym is)?
(1) Not to imply that the C2 prediction is boring/lacking merit.
Over the Internet, this is a problem. Over the intranet, this is a You Can Own Someone's Admin Cookie In 30 Minutes With A Nearly Trivial Ruby Script, because the timing attack is orders of magnitude easier. (You get nanosecond precision in measurements using only thousands of probe requests.)
The cloud angle to this is that deploying on Heroku / Slicehost / EC2 / etc would let the attacker, for the price of a stolen credit card (or less!), trivially get a local network vantage point from which to attack your application.