Attacking Hypervisors
via Firmware and Hardware
Mikhail Gorobets, Oleksandr Bazhaniuk, Alex Matrosov,
Andrew Furtak, Yuriy Bulygin
Advanced Threat Research
Agenda
Hypervisor based isolation
Firmware rootkit vs hypervisor
Attacking hypervisor emulation of hardware devices
Attacking hypervisors through system firmware
Tools and mitigations
Conclusions
Hypervisor Based Isolation
Image source
Hypervisor Based Isolation
Virtual Machine Virtual Machine
App App App App
Operating System Operating System
Privilege
VMM / Hypervisor
System Firmware
(BIOS, U/EFI firmware, SMI handlers, Coreboot…)
Hardware
Memory CPU Graphics
I/O Network
Hypervisor Based Isolation
Virtual Machine Virtual Machine
App App App Attack
Operating System Operating System
Privilege
VMM / Hypervisor
System Firmware
(BIOS, U/EFI firmware, SMI handlers, Coreboot…)
Hardware
Memory CPU Graphics
I/O Network
Hypervisor Protections
Software Isolation
CPU / SoC: traps to hypervisor (VM Exits),
MSR & I/O permissions bitmaps, rings (PV)…
Memory / MMIO: hardware page tables (e.g.
EPT, NPT), software shadow page tables
Devices Isolation
CPU / SoC: interrupt remapping
Memory / MMIO: IOMMU, No-DMA ranges
CPU Virtualization (simplified)
VM Guest OS
Instructions, Access to
exceptions, I/O ports
interrupts… Access to CPU Access to (e.g. 0xB2)
MSRs memory
(e.g. DEBUGCTL) (EPT violations)
Hypervisor Traps (VM Exits)
VMM Host
VM Exit Handler
VM Control Extended Page
MSR Bitmaps I/O Bitmaps
Structure (VMCS) Tables
Protecting Memory with HW Assisted Paging
VM Guest OS VMM Host
VMCS
Guest Physical EPTP Host Physical
CR3
Memory Memory
Process Virtual
Memory GPA0 HPA0
VA0 Guest Page Tables GPA1 EPT HPA1
VA1 GPA2 GPA0 HPA3 HPA2
VA2 GPA3 GPA2 HPA5 HPA3
VA3 GPA4 GPA4 HPA4 HPA4
(1:1 mapping)
VA4 GPA5 HPA5
GPA6 block
… GPA6 HPA6
… …
Hypervisor Protections
System Firmware Isolation
Firmware Rootkit
vs Hypervisor
Image source
What is firmware rootkit?
Virtual Machine Virtual Machine
App App App App
Operating System Operating System
Privilege
VMM / Hypervisor
Rootkit
System Firmware
(e.g. DXE driver)
Hardware
Memory CPU Graphics
I/O Network
Firmware rootkit can open a backdoor for
an attacker VM to access all other VMs
Virtual Machine Attacker VM 3. Now using this
backdoor, attacker VM
App App App App can access all of
memory of victim VMs
Operating System Operating System
2. During each boot
rootkit installs a
Backdoor backdoor for an
attacker controlled VM
VMM / Hypervisor
1. At some point
System Firmware Rootkit system firmware got
infected with a rootkit
staying persistent
“Backdoor” for attacker’s VM
1. Firmware rootkit
searches & modifies VM’s
VMCS(B), VMM page tables
2. Rootkit added page
table entries to attacker
VM which expose entire
physical memory
Now attacker VM has full
access to physical memory
of VMM and other VMs
So how would one install a rootkit in
the firmware?
Using hardware SPI flash programmer…
USB & exploiting weak firmware protections...
Software access and exploiting some
vulnerability in firmware …
From privileged guest (e.g. Dom0). Requires
privesc from normal guest (e.g. DomU) or remote
From the host OS before/in parallel to VMM
From normal guest if firmware is exposed to the
guest by VMM
For example, if firmware is not adequately
write protected in system flash memory
DEMO
Rootkit in System Firmware Exposes
Secrets from Virtual Machines
Image source
Installing rootkit in firmware from root partition
Attacker VM exposes secrets of other VMs
through a backdoor opened by the rootkit
We flashed rootkited part of firmware image
from within a root partition to install the rootkit
The system doesn’t properly protect
firmware in SPI flash memory so we could
bypass write-protection
Finally more systems protect firmware on the
flash memory
common.bios_wp
CHIPSEC module to test write-protection
Malware can exploit vulnerabilities in firmware
to install a rootkit on such systems
Attacking and Defending BIOS in 2015
VMM “forensics”
With the help of a rootkit in firmware any VM guest
can extract all information about hypervisor and other
VMs … and just from memory
VMCS structures, MSR and I/O bitmaps for each VM guest
EPT for each VM guest
Regular page tables for hypervisor and each VM guest
IOMMU pages tables for each IOMMU device
Full hypervisor memory map, VM exit handler…
Real hardware configuration (registers for real PCIe devices,
MMIO contents…)
VMCS, MSR and I/O bitmaps..
VMM Hardware Page Tables…
Attacking Hypervisor Emulation of
Hardware Devices
Image source
Hardware Emulation Attack Vectors
CVE-2014-0983
VM Guest OS
Cloudburst
MS13-092
SYSRET
XSA-122
XSA-138
XSA-108
XSA-75
VENOM
…
…
…
…
Instructions Hypercall Access to
Access to
(CPUID…) API device I/O
Access to device MMIO,
ports
CPU MSRs CMD buffers…
VMM Host
Hypervisor
Device
INSTR CPU MSR Hypercall Device I/O
MMIO/Buffers
Emulation Emulation Impl Emulation
Emulation
Did you know that VMMs emulate virtual
devices of other VMMs?
So Cloudburst was fixed in VMWare but … QEMU and
VirtualBox also emulate VMWare virtual SVGA device
Virtual Machine
App App
Operating System
Virtual sVGA Device
SVGA_CMD_RECT_FILL
…
Host / Hypervisor sVGA commands
Frame buffer
FIFO buffer
Guest to Host Memory Corruption
QEMU / KVM
CVE-2014-3689
3 vulnerabilities in the vmware-vga driver in QEMU allows local guest
to write to QEMU memory and gain host/hypervisor privileges via
unspecified parameters related to rectangle handling
Oracle VirtualBox (Jan 2015 Critical Patch Update)
CVE-2014-6588
Memory corruption in VMSVGAGMRTRANSFER
CVE-2014-6589, CVE-2014-6590
Memory corruptions in VMSVGAFIFOLOOP
CVE-2015-0427
Integer overflow memory corruption in VMSVGAFIFOGETCMDBUFFER
Crashing Host or Guest from Ring3 …
CVE-2015-0377
Writing arbitrary data to upper 32 bits of IA32_APIC_BASE MSR
causes VMM and host OS to crash on Oracle VirtualBox 3.2,
4.0.x-4.2.x
# chipsec_util.py msr 0x1B 0xFEE00900 0xDEADBEEF
CVE-2015-0418, CVE-2014-3646
VirtualBox and KVM guest crash when executing INVEPT/INVVPID
instructions in Ring3
VirtualBox KVM
INVEPT : VM crash INVEPT : VM crash
INVVPID : VM crash INVVPID : VM crash
VMCALL : #UD fault VMCALL : No Exception
VMLAUNCH : #UD fault VMLAUNCH : #UD fault
VMRESUME : #UD fault VMRESUME : #UD fault
Attacking Hypervisors through
System Firmware
(with OS kernel access)
Image source
Pointer Vulnerabilities in SMI Handlers
Phys Memory
SMI Handlers in
RAX (code) SMI SMRAM
RBX (pointer) Fake structure inside SMRAM
RCX (function)
RDX OS Memory
RSI
RDI
Exploit tricks SMI handler to write to an address inside SMRAM
Attacking and Defending BIOS in 2015
Exploiting firmware SMI handler to attack VMM
Virtual Machine Root partition
(child partition) VMM allows VM to
App App App Attack invoke SMI handlers
(grants access to SW
SMI I/O port 0xB2)
Operating System Operating System
Compromised VM
SMI Pointer
injects SMM payload
Hypervisor through the input
pointer vulnerability in
SMI Handlers SMI handler
System Firmware
SMM firmware
Hardware payload modifies
Memory CPU Graphics hypervisor code or
VMCS/EPT to install
I/O Network
a backdoor
DEMO
Attacking Hypervisor via
Poisonous Pointers in Firmware SMI handlers
Root cause? Port B2h is open to VM in I/O bitmap
So that’s a firmware issue! Firmware has
to validate pointers
Phys Memory
SMI Handlers in
RAX (code) SMI SMRAM
RBX (pointer)
RCX (function)
RDX Hypervisor Memory
(Protected by EPT)
RSI
RDI
Firmware SMI handler validates input pointers to ensure they
are outside of SMRAM preventing overwrite of SMI code/data
Point SMI handler to overwrite VMM page!
Phys Memory
SMI Handlers in
RAX (code) SMI SMRAM
RBX (pointer)
RCX (function)
VMM
RDX Hypervisor Memory Protections
(Protected by EPT) are OFF
RSI VMM Protected Page
RDI
• VT state and EPT protections are OFF in SMM (without STM)
• SMI handler writes to a protected page via supplied pointer
Attacking VMM by proxying through SMI handler
Virtual Machine Root partition
(child partition)
VM with direct access to
App App App Attack SMIs invokes SMI
handler and supplies a
pointer to some VMM
Operating System Operating System page
VMM / Hypervisor
SMI Handlers SMI handler writes to
System Firmware the supplied pointer
overwriting contents of
Hardware protected VMM page
Memory CPU Graphics
I/O Network
Sometimes attacker doesn’t need a
vulnerability in firmware…
When VMM grants VM direct access to
firmware or hardware interfaces
VM exploit doesn’t always need to exploit
firmware first through these interfaces
It may use firmware or hardware as a
confused deputy and attack VMM through
some function on behalf of firmware
Read excellent paper Hardware Involved
Software Attacks by Jeff Forristal
Do Hypervisors Dream
of Electric Sheep?
Vulnerability used in this section is VU#976132 a.k.a. S3 Resume
Boot Script Vulnerability independently discovered by ATR of Intel
Security, Rafal Wojtczuk of Bromium and LegbaCore
It’s also used in Thunderstrike 2 by LegbaCore & Trammell Hudson
Waking the system from S3 “sleep” state
Virtual Machine
Apps / OS
VMM / Hypervisor
U/EFI System Firmware
BDS
NORMAL BOOT
S3 RESUME
DXE S3 Boot
Script Table
UEFI core
Restores
& drivers hardware config
Script Engine
Platform Init Platform Init
What is S3 boot script table?
A table of opcodes in physical memory which restores
platform configuration
S3_BOOTSCRIPT_MEM_WRITE opcode writes some value to
specified memory location on behalf of firmware
S3_BOOTSCRIPT_DISPATCH/2
S3_BOOTSCRIPT_PCI_CONFIG_WRITE
S3_BOOTSCRIPT_IO_WRITE
…
Xen exposes S3 boot script table to Dom0
VM modifies S3 boot
Privileged PV guest (Dom0) script table in memory
Upon resume, firmware
Exploit
executes rogue S3 script
Xen Hypervisor
MODIFY
U/EFI System Firmware
BDS
NORMAL BOOT
S3 RESUME
DXE S3 Boot
Script Table
UEFI core
Restores
& drivers hardware config
Script Engine
Platform PEI 0xDBAA4000 Platform PEI
Xen attack via S3 boot script
Found S3 boot script
table in memory
accessible to Dom0
Changing the boot
script to access Xen
hypervisor pages
Dumping Dom0
VMCS from memory
protected by EPT
DEMO
Attacking Xen
in its sleep
Image source
Déjà vu?
Xen 0wning Trilogy (Part 3) by Invisible Things Lab
So these firmware vulnerabilities are
exploitable from privileged guest (e.g. root
partition, Dom0 ..)
What about use cases where guests must
be strongly isolated from the root
partition?
Tools and Mitigations
Image sciencenews.org
First things first - fix that firmware!
Firmware can be tested for vulnerabilities!
common.uefi.s3bootscript
(tests S3 boot script protections)
tools.smm.smm_ptr
(tests for SMI pointer issues)
Protect the firmware in system flash memory
common.bios_wp
common.spi_lock
...
(tests firmware protections in system flash memory)
Testing hypervisors…
Simple hardware emulation fuzzing
modules for open source CHIPSEC
tools.vmm.*_fuzz
I/O, MSR, PCIe device, MMIO overlap, more soon …
Tools to explore VMM hardware config
chipsec_util iommu (IOMMU)
chipsec_util vm (CPU VM extensions)
Dealing with system firmware attacks..
A number of interfaces through which
firmware can be attacked or relay attack onto
VMM
UEFI variables, SMI handlers, S3 boot script, SPI flash
MMIO, FW update..
FW doesn’t know memory VMM needs to protect
VMM need to be careful with which of these it
exposes to VMs including to administrative
(privileged) guests
Some need not be exposed (e.g. S3 boot script), some
may be emulated and monitored
Conclusions
• Compromised firmware is bad news for VMM.
Test your system’s firmware for security issues
• Windows 10 enables path for firmware
deployment via Windows Update
• Secure privileged/administrative guests; attacks
from such guests are important
• Vulnerabilities in device and CPU emulation are
very common. Fuzz all HW interfaces
• Firmware interfaces/features may affect
hypervisor security if exposed to VMs. Both need
to be designed to be aware of each other
References
1. CHIPSEC: https://github.com/chipsec/chipsec
2. Intel’s ATR Security of System Firmware
3. Attacking and Defending BIOS in 2015 by Intel ATR
4. Hardware Involved Software Attacks by Jeff Forristal
5. Xen 0wning Trilogy by Invisible Things Lab
6. http://www.legbacore.com/Research.html
7. Low level PC attack papers by Xeno Kovah
Thank You!
