Attacking Hypervisors

via Firmware and Hardware

Alex Matrosov (@matrosov),
Mikhail Gorobets,
Oleksandr Bazhaniuk (@ABazhaniuk),
Andrew Furtak,
Yuriy Bulygin (@c7zero)

Advanced Threat Research

Agenda

Hypervisor based isolation

Firmware rootkit vs hypervisor
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
https://youtu.be/sJnIiPN0104
Image source
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…)
VMM Hardware Page Tables…
 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
https://youtu.be/zUJEL9cGSE8
Root cause? Port B2h is open to VM in I/O bitmap
So this is firmware issue, right? What
if firmware validates pointers?
 Still exploitable…

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

 DEMO
Attacking Xen
in its sleep

https://youtu.be/Dsu-scEJyJg

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!