This right here is why you'd want to have a job in my field.
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.)
Wow. I think Dowd just lost his spot as the king of insane, Rube Goldberg-esque exploits. I'd love to hear not just how the exploit works, but how all of this was discovered.
I think Travis Goodspeed nailed this on Twitter: any time you're emulating or even just retrofitting one complex system into another, you can catalog the security assumptions made by both systems and look for clashes.
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.
The "why it doesn't work on Win7" thing is that they started to emulate VGABIOS - probably to still support the VGA init on 64bit windows without needing the 16bit realmode stuff around.
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.
* 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.
To be more precise, the IVT is a table of 4-byte 16:16 far pointers typically located at address zero that is used in real mode. When a x86 processor in real mode encounters an interrupt, it looks up this table and does a far call to the address. The IDT is used in protected mode which contains additional information, and thus is 8 bytes per entry (in long mode, 16 bytes).
A vulnerability/exploit like this was only a matter of time. With cloud computing getting ever more popular I think it's only a matter of time before something like this causes a complete and total outage for EC2 or Rackspace or $Cloud_Provider. Security in the virtualization space should be focused on stuff like this because everything else can be addressed with traditional methods.
Two issues that I think will matter more to cloud app platforms than VM breakouts (am interested to see how wrong I'll be proven here):
* 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.
Do you think there is anything "cloud specific"[1] about the web app vulns in the control plane? Or is this just the bread and butter targeting of command and control?
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.
Yes: the control plane infrastructure for cloud providers is (a) usually sole-sourced to the cloud provider, (b) usually custom-build, (c) often ad-hoc, and (d) virtually always multi-tenant.
I think (d) is the compelling answer. I'm not sure I think that (a-c) are really all that unique to cloud environments. The same can be said for a lot of niche and/or legacy environments dominated by one or two firms.
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.
An example of the attack Thomas is talking about: Rails and Django were both bitten earlier last year (?) because their session cookies used HMACs to avoid tampering. Those HMACs were compared against the expected ones using the == operator, which short circuits in Ruby/Python, causing the comparison to be timeable.
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.
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.)