
VMware High-Bandwidth Backdoor ROM Overwrite Privilege Elevation  - wglb
http://www.securityfocus.com/archive/1/522141
======
tptacek
Hint book:

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

~~~
yuhong
>the "nobody's ever going to need more than 640k of memory" mode

FTFY.

~~~
tptacek
Thanks. What's your background in this stuff?

~~~
yuhong
I am a fan of computer history and know a lot about C and x86 assembly.

~~~
tptacek
Obviously. I was just curious if you did a lot of kernel x86 code in your day
job.

------
tptacek
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.)

~~~
daeken
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.

~~~
tptacek
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.

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

~~~
yuhong
Yea, Virtual 8086 mode is not supported in long mode.

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

~~~
tptacek
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.

~~~
dfc
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.

~~~
tptacek
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.

~~~
dfc
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.

~~~
patio11
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.

