Attacking and Defending

BIOS in 2015

Oleksandr Bazhaniuk, Yuriy Bulygin (presenting), Andrew Furtak,

Mikhail Gorobets, John Loucaides, Alex Matrosov, Mickey Shkatov

Advanced Threat Research

Agenda

State of BIOS/EFI Firmware Security

Recent Classes of Vulnerabilities
S3 Resume Boot Script
Firmware Configuration (UEFI Variables)
Input Pointers in SMI Handlers
Call-Outs in SMI Handlers
Detecting and Mitigating These Vulnerabilities
Conclusions
 Plain Ordinary Art of
Breaking BIOS...

* Quotes are from or based on novels by Strugatsky brothers

We seem to have a bit of a problem

37 unique publicly disclosed issues in the last ~2 years

(by only a handful of researchers)
Multiple of these are really classes of issues with many
instances in affected firmware products (SMI input
pointers, SMI call-outs, indiscriminate use of UEFI vars..)
Many same issues affect multiple vendors at once (S3
boot script, UEFI variables, SMI call-outs, SMI input
pointers, missing basic BIOS write protections)
Issues in open source EDK reference implementation
may find their way in multiple UEFI firmware products
And updating system firmware is not an easy thing
 Jolly Ghosts (2013-2014)
Vulnerability Ref Affected Discoverer
EFI firmware is not write protected (attack on Full-Disk Encryption with CSW2013, Intel ATR,
TPM aka Angry Evil Maid, subverting TPM measured boot). In 2009, NoSuchCon MITRE,
Sacco & Ortega discovered legacy BIOS were not write protected 2013 LegbaCore
Secure Boot bypass due to SPI flash protections are not used BH2013
Secure Boot bypass due to PE/TE Header confusion CSW2014
Multiple
Secure Boot bypass due to CSM default enabled or CSM CSW2014
enable/disable stored in Setup (2 issues) Intel ATR
Secure Boot bypass due to Clear keys and Restore default keys CSW2014
stored in Setup
Secure Boot bypass due to ignoring SecureConfig integrity mismatch CSW2014
Secure Boot bypass via on/off switch stored in Setup variable CSW2014 Multiple Intel ATR,
LegbaCore
Unauthorized modification of UEFI variables in UEFI systems (Secure VU#758382 Multiple LegbaCore,
Boot policies stored in Setup, corrupting Setup contents) 2 issues Tianocore Intel ATR
SMM Cache attack protections (SMRR) not enabled (The Sicilian) VU#255726 Multiple

Dell BIOS in some Latitude laptops and Precision Mobile Workstations VU#912156 Dell
vulnerable to buffer overflow (Ruy Lopez)
LegbaCore
SMI Suppression if SMM BIOS protection is not used (Charizard) VU#291102 Multiple

Intel BIOS locking mechanism contains race condition that enables VU#766164 AMI,
write protection bypass (Speed Racer) Phoenix
 Exploding Rainbows (2014)
Vulnerability Ref Affected Discoverer
UEFI EDK2 Capsule Update vulnerabilities a.k.a. King and Queens VU#552286 Multiple, LegbaCore
Gambit (2 issues) Tianocore EDK2
UEFI Variable Reinstallation (bypassing Boot-Service only variables) Tianocore Multiple,
Intel ATR
EDK2
Insecure Default Secure Boot Policy for Option ROMs

Incorrect PKCS#1v1.5 Padding Verification for RSA Signature Check

Overwrite from PerformanceData Variable

CommBuffer SMM Overwrite/Exposure (3 issues)

TOCTOU (race condition) Issue with CommBuffer (2 issues)

SMRAM Overwrite in Fault Tolerant Write SMI Handler (2 issues)

Tianocore EDK2 Intel ATR
SMRAM Overwrite in SmmVariableHandler (2 issues)
Integer/Heap Overflow in SetVariable

Heap Overflow in UpdateVariable

Overwrite from FirmwarePerformance Variable

Integer/Buffer Overflow in TpmDxe Driver

Protection of PhysicalPresence Variable

 Spitting Devil's Cabbage (2014-2015)
Vulnerability Ref Affected Discoverer
Boot Failure Related to UEFI Variable Usage (36 issues) Tianocore EDK2 Intel ATR, TianoCore
dev, LegbaCore
Boot Failure Related to TPM Measurements Tianocore EDK2 TianoCore dev
Tianocore UEFI implementation reclaim function vulnerable to VU#533140 EDK2, Rafal Wojtczuk,
buffer overflow (2 issues) Tianocore Insyde LegbaCore
Overflow in Processing of AuthVarKeyDatabase Tianocore EDK2 Rafal Wojtczuk,
LegbaCore
Counter Based Authenticated Variable Issue Tianocore EDK2 TianoCore dev
Some UEFI systems do not properly secure the EFI S3 VU#976132 Multiple Rafal Wojtszuk, Intel
Resume Boot Path boot script (Venamis) ATR, LegbaCore
Some BIOS protections are unlocked on resume (Snorlax) VU#577140 LegbaCore

Loading unsigned Option ROMs (Thunderstrike) based on trmm.net Apple Trammell Hudson
earlier work by @snare
SMI input pointer validation vulnerabilities (multiple issues) CSW2015 Multiple Intel ATR
SMI handler call-out vulnerabilities (multiple issues) LegbaCore Multiple LegbaCore
Earlier by Filip Wecherowski & ITL (bugtraq, ITL)

SPI flash configuration lock (FLOCKDN) is lost after resume reverse.put.as Apple Pedro Vilaa
from S3 sleep (Update: Apple advisory) Update: Trammell
Hudson, LegbaCore

The list may be incomplete

Your BIOS is definitely maybe
vulnerable
 This is one way to handle the problem

http://sovietart.me/
Calm silence ends the history of
mankind...
So lets talk what needs to be done
But, first, why we need any changes

Attacks via S3 Resume Boot Script

#S3SleepResumeBootScript
Attacks via UEFI Variables
#BadBIOSVariableContents
Attacks via Bad SMI Handlers Input Pointers
#SMIHandlerBadInputPointers
Attacks via SMI Handlers Call-Outs
#ThisVulnSeriouslyHadToBeGoneLongAgo
Attacking Firmware
via S3 Resume
Boot Script

Image source
VU# 976132 (CVE-2014-8274)

Freddy Krueger vulnerabilities (S3 Resume Boot Script)

were independently discovered by us and other security
researchers
Rafal Wojtczuk of Bromium and Corey Kallenberg
(@coreykal) of LegbaCore first published Attacks on UEFI
Security (paper)
Details of PoC exploit were described by Dmytro Oleksiuk
(@d_olex) in Exploiting UEFI boot script table vulnerability
Pedro Vilaa (@osxreverser) disclosed a related
vulnerability in Mac EFI firmware (SPI Flash Configuration
HW lock bit FLOCKDN is gone after waking from sleep)
Searching for ACPI global structure

AcpiGlobalVariable UEFI variable points to a structure in

memory (ACPI_VARIABLE_SET_COMPATIBILITY)

[CHIPSEC] Reading EFI variable Name=AcpiGlobalVariable..

[uefi] EFI variable AF9FFD67-EC10-488A-9DFC-
6CBF5EE22C2E:AcpiGlobalVariable:
18 be 89 da
Searching for S3 Boot Script

Pointer AcpiBootScriptTable at offset 0x18 in the structure

ACPI_VARIABLE_SET_COMPATIBILITY points to the script table

typedef struct {
//
// Acpi Related variables
//
EFI_PHYSICAL_ADDRESS AcpiReservedMemoryBase;
UINT32 AcpiReservedMemorySize;
EFI_PHYSICAL_ADDRESS S3ReservedLowMemoryBase;
EFI_PHYSICAL_ADDRESS AcpiBootScriptTable;
..
} ACPI_VARIABLE_SET_COMPATIBILITY;
S3 Boot Script table in memory
Why S3 Resume Boot Script?

To speed up S3 resume, required HW configuration actions are

written to an S3 Resume Boot Script by DXE drivers instead of
running all configuration actions normally performed during boot
S3 Boot Script is a Sequence of Platform
Dependent Opcodes

00 00 00 00 21 00 00 00 02 00 0f 01 00 00 00 00
00 00 c0 fe 00 00 00 00 01 00 00 00 00 00 00 00
00 01 00 00 00 24 00 00 00 02 02 0f 01 00 00 00
00 04 00 c0 fe 00 00 00 00 01 00 00 00 00 00 00
00 00 00 00 08 02 00 00 00 21 00 00 00 02 00 0f
01 00 00 00 00 00 00 c0 fe 00 00 00 00 01 00 00
00 00 00 00 00 10 03 00 00 00 24 00 00 00 02 02
..
01 00 00 00 00 00 00 00 f0 00 02 00 67 01 00 00
20 00 00 00 01 02 30 04 00 00 00 00 21 00 00 00
00 00 00 00 de ff ff ff 00 00 00 00 68 01 00 00
..
d3 d1 4b 4a 7e ff
Decoding Opcodes
[000] Entry at offset 0x0000 (length = 0x21):
Data:
02 00 0f 01 00 00 00 00 00 00 c0 fe 00 00 00 00
01 00 00 00 00 00 00 00 00
Decoded:
Opcode : S3_BOOTSCRIPT_MEM_WRITE (0x02)
Width : 0x00 (1 bytes)
Address: 0xFEC00000
Count : 0x1
Values : 0x00
..

[359] Entry at offset 0x2F2C (length = 0x20):

Data:
01 02 30 04 00 00 00 00 21 00 00 00 00 00 00 00
de ff ff ff 00 00 00 00
Decoded:
Opcode : S3_BOOTSCRIPT_IO_READ_WRITE (0x01)
Width : 0x02 (4 bytes)
Address: 0x00000430
Value : 0x00000021
Mask : 0xFFFFFFDE

# chipsec_util.py uefi s3bootscript

S3 Boot Script Opcodes
I/O port write (0x00)
I/O port read-write (0x01)
Memory write (0x02)
Memory read-write (0x03)
PCIe configuration write (0x04)
PCIe configuration read-write (0x05)
SMBus execute (0x06)
Stall (0x07)
Dispatch (0x08) / Dispatch2 (0x09)
Information (0x0A)

Processor I/O Port Opcodes

S3_BOOTSCRIPT_IO_WRITE/READ_WRITE opcodes in the S3

boot script write or RMW to processor I/O ports
Opcode below sends SW SMI by writing value 0xBD port 0xB2
Dispatch Opcodes

S3_BOOTSCRIPT_DISPATCH/2 opcodes in the S3 boot script

jumps to entry-point defined in the opcode
Opcode Restoring BIOS Write Protection

S3_BOOTSCRIPT_PCI_CONFIG_WRITE opcode in the S3 boot

script restores BIOS hardware write-protection (value 0x2A
indicates BIOS hardware write protection is ON)
So what can go wrong with the script?

Address (pointer) to S3 boot script is stored in a runtime

UEFI variable (e.g. NV+RT+BS AcpiGlobalTable)
The S3 boot script itself is stored in unprotected memory
(ACPI NVS) accessible to the OS or DMA capable devices
The PEI executable parsing and interpreting the S3 boot
script or any other executable needed for S3 resume is
running out of unprotected memory
S3 boot script contains Dispatch (Dispatch2) opcodes
with entry-points in unprotected memory
EFI firmware forgets to store opcodes which restore all
required hardware locks and protections in S3 boot script
So whats the impact?

Malware in the OS may be able to change the actions that

are performed by firmware on S3 resume before the OS
resumes at the waking vector

Ok And?
Execute arbitrary firmware code during early resume
Disable hardware protections such as BIOS write
protection which are going to be restored by the script
Install persistent BIOS rootkit in the SPI flash memory
Read/write any memory or execute arbitrary code in the
context of system firmware during early boot (PEI)
Bypass secure boot of the OS and install UEFI Bootkit
Yes, It Can Your
Steal PGP keys!

Forbes

Image source: http://www.imdb.com/title/tt0439581/

83% of all days in a year start the same:
alarm clock rings

then vulnerable BIOS awakes

Attacking S3 Boot Script (Demo)
Lucky you! BIOS protection is ON

PASSED: BIOS is write

protected
Sleep well
Found Boot Script in
unprotected memory

Script Opcode restores

BIOS Protection == ON

Changing it to OFF
Oh wait

FAILED: BIOS is NOT

protected completely
Opcode restoring BIOS Write Protection
has been modified
S3_BOOTSCRIPT_PCI_CONFIG_WRITE opcode in the S3 boot
script restored BIOS hardware write-protection in OFF state
Detecting & Mitigating
S3 Resume Boot Script Issues
Theres a script to detect these issues
# chipsec_main.py m common.uefi.s3bootscript

[x][ ==========================================
[x][ Module: S3 Resume Boot-Script Protections
[x][ ==========================================
[!] Found 1 S3 boot-script(s) in EFI variables
[*] Checking S3 boot-script at 0x00000000DA88A018
[!] S3 boot-script is not in SMRAM
[*] Reading S3 boot-script from memory..
[*] Decoding S3 boot-script opcodes..
[*] Checking entry-points of Dispatch opcodes..
[-] Found Dispatch opcode (offset 0x014E) with Entry-Point:
0x00000000DA5C3260 : UNPROTECTED

[-] Entry-points of Dispatch opcodes in S3 boot-script are

not in protected memory
[-] FAILED: S3 Boot Script and entry-points of Dispatch
opcodes do not appear to be protected
Fixing S3 Boot Script Protections

1. Do not keep address of S3 Boot Script table (or a

structure with a pointer to the table) in unprotected NV
UEFI variable (ex. NV+RT+BS AcpiGlobalVariable)
2. Do not save the S3 Boot Script table to memory
accessible by the OS or DMA capable devices (e.g. use
EDKII LockBox)
3. Do not save the PEI executable that parses and executes
the S3 Boot Script table and any other PEI executable(s)
needed for S3 resume to memory accessible by the OS
or DMA capable devices
4. Review the S3 Boot Script for Dispatch opcodes and
establish whether the target code is protected.
 Protecting S3 Boot Script with LockBox

A Tour Beyond BIOS Implementing S3 Resume with EDKII

LockBox: https://github.com/tianocore/edk2-MdeModulePkg/blob/master/Include/Protocol/LockBox.h
Saving S3 Boot Script to LockBox
SaveBootScriptDataToLockBox():

//
// mS3BootScriptTablePtr->TableLength does not include
EFI_BOOT_SCRIPT_TERMINATE, because we need add entry at runtime.
// Save all info here, just in case that no one will add boot
script entry in SMM.
//
Status = SaveLockBox (
&mBootScriptDataGuid,
(VOID *)mS3BootScriptTablePtr->TableBase,
mS3BootScriptTablePtr->TableLength +
sizeof(EFI_BOOT_SCRIPT_TERMINATE)
);
ASSERT_EFI_ERROR (Status);
Status = SetLockBoxAttributes (&mBootScriptDataGuid,
LOCK_BOX_ATTRIBUTE_RESTORE_IN_PLACE);

https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c
Attacking EFI Firmware via
UEFI Variables
 Where does firmware store its settings?

UEFI BIOS stores persistent config

as UEFI Variables in NVRAM part
of SPI Flash chip
UEFI Variables can be Boot-time or
Run-time
Run-time UEFI Variables are
accessible by OS via run-time
Variable API (via SMI Handler)
OS exposes UEFI Variable API to
[privileged] user-mode applications
SetFirmwareEnvironmentVariable
/sys/firmware/efi/efivars/ or
/sys/firmware/efi/vars
39
Image Source: Adafruit
Lots of settings

AcpiGlobalVariable

BootOrder

Secure Boot
certificates
(PK, KEK, db, dbx)

Setup
Things we found in unprotected runtime
(read user-mode) accessible variables

Secure Boot configuration (All You Boot Are Belong To Us)

Addresses to structures/buffers which firmware reads from or
writes to during boot
Policies for hardware protections & locks such as BIOS
Write Protection, Flash LockDown, BIOS Interface Lock
Policies disabling security features

Data which firmware really really needs to just boot

Secrets: BIOS passwords in clear
This cannot be good
Overwrite early firmware code/data if
(physical addresses) pointers are stored
in unprotected variables
Bypass UEFI and OS Secure Boot if
its configuration or keys are stored in
unprotected variables
Bypass or disable hardware
protections if their policies are stored in
unprotected variables
Make the system unable to boot
(brick) if setting essential to boot the
system are stored in unprotected
variables

Image Source: The Atlantic

But that was a theory. In practice

Multiple unique vulnerabilities (~50 instances), related to UEFI

variables, were discovered only recently
Both in EFI firmware and in open source Tiano reference
implementation
Resulted in
OS Secure Boot bypass due to settings stored in EFI variables
Unbootable platform due to corruption of EFI variable contents
Buffer overflows when consuming EFI variable contents
Arbitrary overwrites due to pointers in EFI variables
Bypassing Boot-Services protection by re-installing as Runtime
Bypassing physical presence protection of EFI variables
Who needs a Setup variable, anyway?

VU#758382
Storing Secure Boot settings in Setup
could be bad
Now user-mode malware can clobber
contents of Setup UEFI variable with
garbage or delete it
Malware may also clobber/delete
default configuration (StdDefaults)
The system may never boot again

The attack has been co-discovered with researchers from

LegbaCore (Corey Kallenberg, Xeno Kovah) and MITRE
Corporation (Sam Cornwell, John Butterworth).

Source: Setup For Failure

Image Source: Anchorman
Why bother? Just bring it to IT and ask to
re-install firmware

Image Source: Intel ATR ;)

 You may as well bring this

Image Source: Anchorman

Avoiding Problems with UEFI Variables
Image Source: KEEP CALM-O-MATIC
Limit Access to UEFI Variables

Separate critical settings from other setting. Store them in

different variables with different protections
Remove RUNTIME_ACCESS attribute
Make them Read-Only via VARIABLE_LOCK_PROTOCOL
Use UEFI Authenticated Variables
Remove debug/test content (e.g. HW lock policies)
Use PCD instead of variables
Some variables require user present (e.g. SetupMode)
May implement integrity checks for critical variables
Storing BIOS passwords or other sensitive content in
variables in clear is not a good protection
Validate Contents of UEFI Variables

Assume contents of the variables are malicious. Validate

them before consuming
Is there an address in the variable? Is it pointing to your
own code/data?
Validate data written to variables is within allowed range
Can you boot if variable is corrupted? If no, apply
defaults and enter recovery
Recover to defaults if critical settings are invalid or
missing. Implement a catastrophic recovery
Read-Only Variables (Variable Lock)

RequestToLock(MyVar) SetVariable API enforces

that MyVar is Read-Only
MyVar is still writeable

UEFI DXE UEFI OS OS

VARIABLE_LOCK Exit
EndOfDxe BootServices
Protocol Loaded

EDKII reference code implements Variable Lock Protocol:

https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Include/Protocol/VariableLock.h
 Poisonous Pointers

Attacking SMI Handlers via

Unvalidated Input Pointers

Image source
Where there is no BIOS, there is
boredom. BIOS makes life interesting.
System Management Interrupt (SMI) Handlers

0xFFFFFFFF

Protected SMRAM
SMRAM
SMI code lives here SMBASE + FFFFh
SMM state
SMRAM Base
save area
SMBASE + FC00h

SMI handlers
SMBASE + 8000h

0x00000000 SMBASE
 Pointer Arguments to SMI Handlers

Phys Memory
SMI Handlers in
RAX (code) SMI SMRAM
RBX (pointer)
RCX (function)
RDX OS Memory
RSI SMI handler specific structure

RDI

SMI Handler writes result to a buffer at address passed in RBX

 If SMI Handler Doesnt Check Pointers

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

What to overwrite inside SMRAM?
Exploit often doesnt control values written to target address

What can an exploit overwrite in SMRAM?

SMI handler code starting at SMBASE + 8000h
Internal SMI handlers state/flags inside SMRAM
Contents of SMM state save area at SMBASE + FC00h, where the
CPU state is stored on SMM entry

Current value of SMBASE value is also saved in state save area at

offset FEF8h and restored on SMM exit (RSM)

An exploit can move SMRAM to a new, unprotected location by

changing the SMBASE value stored in the SMM state save area
How does exploit know where to write?

1. Dump contents of SMRAM to find SMBASE

Use another vulnerability (e.g. S3 boot script) to disable SMRAM
protections and use DMA or graphics to read SMRAM
Read SPI flash, extract SMM EFI binaries and RE SMM init code
Use similar SMI pointer read vulnerability to expose SMRAM
Use hardware JTAG debugger offline

2. Exploit can guess location of SMBASE

Try SMBASE locations equal to SMRR base or SMRR base
8000h (SMRR base at SMI entry point)
Blind iteration through all offsets within SMRAM as potential
saved SMBASE value
 One way to acquire contents of SMRAM

4GB
Low MMIO Range Access to GFx Aperture is
GTT MMIO redirected to SMRAM

Graphics Aperture

TOLUD
GTT PTEs

GFx Mem Base

TSEG Base DMA access to SMRAM
SMRAM
is not blocked as TSEG
Base moved
 How does the attack work?

Phys Memory
RAX (code) SMI Saved SMBASE value SMM State Save Area
RBX (pointer)
RCX (function) SMI Entry Point
SMI Handler (SMBASE + 8000h)
SMBASE

OS Memory
SMI handler specific structure

CPU stores current value of SMBASE in SMM save state area on SMI
and restores it on RSM
 How does the attack work?

Phys Memory
Saved SMBASE value SMM State Save Area

SMI Entry Point

SMI Handler (SMBASE + 8000h)
SMBASE

OS Memory
Fake SMI handler

Exploit prepares fake SMRAM with fake SMI handler outside of SMRAM
 How does the attack work?

Phys Memory
RAX (code) SMI Saved SMBASE value SMM State Save Area
RBX (pointer)
RCX (function) SMI Entry Point
SMI Handler (SMBASE + 8000h)
SMBASE

OS Memory
Fake SMI handler

Exploit triggers SMI w/ RBX pointing to saved SMBASE address in SMRAM

SMI handler overwrites saved SMBASE on exploits behalf with address of
fake SMI handler outside of SMRAM (e.g. 0 PA)
 How does the attack work?

Phys Memory
Saved SMBASE value SMM State Save Area

SMI Handler

SMI OS Memory
Fake SMI handler New SMI Entry Point
SMBASE

Exploit triggers another SMI

CPU executes fake SMI handler at new entry point outside of original
protected SMRAM because SMBASE location changed
 How does the attack work?

Phys Memory
Original saved SMBASE SMM State Save Area
value

SMI Handler
(SMRAM is not protected)

OS Memory
Fake SMI handler New SMI Entry Point
SMBASE

Fake SMI handler disables original SMRAM protection (disables SMRR)

Then restores original SMBASE values to switch back to original SMRAM
 How does the attack work?

Phys Memory

SMI Handler SMI Entry Point

(SMRAM is not protected) (SMBASE + 8000h)
SMBASE

OS Memory

The SMRAM is restored but not protected by HW anymore

Any SMI handler may be installed/modified by malware
Exploiting SMI Input Pointers (Demo)
 EDKII CommBuffer

CommBuffer is a memory buffer used as a communication protocol between OS runtime and DXE
SMI handlers. Pointer to CommBuffer is stored in UEFI ACPI table in ACPI memory
Contents of CommBuffer are specific to SMI handler. Variable SMI handler read UEFI variable
GUID, Name and Data from CommBuffer
Example: VariableAuthenticated SMI Handler reads/writes UEFI variables from/to CommBuffer

Source: A Tour Beyond Implementing UEFI Auth Variables in SMM with EDKII (Jiewen Yao, Vincent Zimmer)
 Attacking CommBuffer Pointer
SmmVariableHandler (
...
SmmVariableFunctionHeader = (SMM_VARIABLE_COMMUNICATE_HEADER *)
CommBuffer;
switch (SmmVariableFunctionHeader->Function) {
case SMM_VARIABLE_FUNCTION_GET_VARIABLE:
SmmVariableHeader = (SMM_VARIABLE_COMMUNICATE_ACCESS_VARIABLE *)
SmmVariableFunctionHeader->Data;
Status = VariableServiceGetVariable (
...
(UINT8 *)SmmVariableHeader->Name + SmmVariableHeader->NameSize
);

VariableServiceGetVariable (
...
OUT VOID *Data
)
...
CopyMem (Data, GetVariableDataPtr (Variable.CurrPtr), VarDataSize);

CommBuffer SMRAM
CommBuffer TOCTOU Issues
SMI handler checks that it wont access outside of CommBuffer
What if SMI handler reads CommBuffer memory again after the check
DMA engine (for example GFx) can modify contents of CommBuffer
Time of Check
InfoSize = .. + SmmVariableHeader->DataSize + SmmVariableHeader->NameSize;
if (InfoSize > *CommBufferSize - SMM_VARIABLE_COMMUNICATE_HEADER_SIZE) {
Status = VariableServiceGetVariable (
...
(UINT8 *)SmmVariableHeader->Name + SmmVariableHeader->NameSize
);

VariableServiceGetVariable (
...
OUT VOID *Data
)
...
Time of Use
if (*DataSize >= VarDataSize) {
CopyMem (Data, GetVariableDataPtr (Variable.CurrPtr), VarDataSize);
Detecting & Mitigating
Unvalidated SMI Input Pointers
Tools For Everybody, Free, And No One
Will Go Away Unsatisfied!
Discovering SMI Pointer Vulns with CHIPSEC

# chipsec_main.py m tools.smm.smm_ptr a config,smm_config.ini

[x][ =======================================================================
[x][ Module: Testing SMI handlers for pointer validation vulnerabilities
[x][ =======================================================================
...
[*] Allocated memory buffer (to pass to SMI handlers) : 0x00000000DAAC3000
[*] >>> Testing SMI handlers defined in 'smm_config.ini'..
...

[*] testing SMI# 0x1F (data: 0x00) SW SMI 0x1F

[*] writing 0x500 bytes at 0x00000000DAAC3000
> SMI 1F (data: 00)
RAX: 0x5A5A5A5A5A5A5A5A
RBX: 0x00000000DAAC3000
RCX: 0x0000000000000000
RDX: 0x5A5A5A5A5A5A5A5A
RSI: 0x5A5A5A5A5A5A5A5A
RDI: 0x5A5A5A5A5A5A5A5A
< checking buffers contents changed at 0x00000000DAAC3000 +[29,32,33,34,35]
[!] DETECTED: SMI# 1F data 0 (rax=5A5A5A5A5A5A5A5A rbx=DAAC3000 rcx=0 rdx=...)

[-] <<< Done: found 2 potential occurrences of unchecked input pointers

Wash pointers before consuming! They
may be poisonous
SMI code has to validate address/pointer (+ offsets) they receive
from OS prior writing to it including returning status/error code
Check input pointer + size for overlap with SMRAM range. E.g.
use SmmIsBufferOutsideSmmValid function in EDKII
Also validate pointers before reading. They can expose SMRAM

SmiHandler() {
// check InputBuffer is outside SMRAM
if (!SmmIsBufferOutsideSmmValid(InputBuffer, Size)) {
return EFI_SUCCESS;
}
switch(command)
case 1: do_command1(InputBuffer);
case 2: do_command2(InputBuffer);
One Missed CALL

Attacking SMI Handlers Via

SMM Call-Outs
#ThisVulnHadToBeGoneLongAgo

In 2009, SMI call-out vulnerabilities were discovered by

Rafal Wojtczuk and Alex Tereshkin in EFI SMI handlers
(Attacking Intel BIOS) and by Filip Wecherowski in legacy
SMI (BIOS SMM Privilege Escalation Vulnerabilities)

Also discussed by Loic Duflot in System Management

Mode Design and Security Issues

In 2015(!) researchers from LegbaCore found that many

modern systems are still vulnerable to these issues How
Many Million BIOS Would You Like To Infect (paper)
These issues seem to come in packs

14 call-out vulnerabilities in one SMI handler!

BIOS SMM Privilege Escalation Vulnerabilities

SMI Handlers Calling Out of SMRAM

Phys Memory
SMRAM
CALL F000:8070

1 MB
Far CALL in
SMM to BIOS
Legacy BIOS Shadow
service outside
(F/ E-segments)
of SMRAM
PA = 0xF0000
SMI Handlers Calling Out of SMRAM

Phys Memory
SMRAM
CALL F000:8070

1 MB
Far CALL in
SMM to BIOS
Legacy BIOS Shadow
service outside
(F/ E-segments)
of SMRAM
PA = 0xF0000
0F000:08070 = 0xF8070: payload
0xF8070 PA
UEFI SMI Call-Outs

DXE SMM drivers

may call Runtime
Services functions
Are SMI call-outs fixed yet?

How Many Million BIOS Would You Like To Infect by LegbaCore

Detecting & Mitigating SMI Call-Outs
Statically analyzing SMI handlers for call-outs

Legacy SMI handlers do far calls to BIOS functions in F/E

segments (0xE0000 0xFFFFF physical memory) with specific
code segment selectors
Statically analyzing SMI handlers for call-outs

Searching where EFI DXE SMM drivers reference/fetch outside of

SMRAM range of addresses with IDAPython plugin by LegbaCore:

How Many Million BIOS Would You Like To Infect by LegbaCore

Dynamically detecting SMM call-outs

DXE SMI drivers may call Runtime, Boot or DXE services API

Find Runtime, Boot and DXE service tables containing UEFI API
function pointers in memory (EFI System Table)
Patch each function with detour code chaining the original function
Enumerate and invoke all SMI handlers
If SMI handler calls-out to some UEFI API, patch will get invoked

Difficulties with this approach:

it needs enumeration of all SMI handlers (with proper interfaces)

SMI handlers may call functions non in RT/BS/DXE service tables
Hooking runtime UEFI services
BIOS developers can easily detect call-outs
1. A simple ITP debugger script to step on branches and verify
that target address of the branch is within SMRAM
2. Enable SMM Code Access Check HW feature on pre-
production systems based on newer CPUs to weed out all
intended code fetches outside of SMRAM from SMI drivers
3. NX based soft SMM Code Access Check patches by Phoenix
look promising
Mitigating SMM Call-Outs

1. Dont call any function outside of protected SMRAM

Violates No read down rule of classical Biba integrity model

2. Enable SMM Code Access Check CPU protection

Available starting in Haswell based CPUs
Available if MSR_SMM_MCA_CAP[58] == 1
When enabled, attempts to execute code not within the ranges
defined by the SMRR while inside SMM result in a Machine Check
Exception
Blocking Code Fetch Outside of SMRAM

Phys Memory
SMRAM
CALL F000:8070

1 MB
Code fetch
Legacy BIOS Shadow in SMM
(F/ E-segments) causes MC
PA = 0xF0000 exception
0F000:08070 =
0xF8070: payload
0xF8070 PA
It's like trying to fit an octopus into a pair
of tuxedo pants
Image source: speckyboy.com
Why are we investing in CHIPSEC?

Security researchers need a way to develop PoCs to test

exploitability and impact of firmware issues
OEM/BIOS vendors need a way to consistently run
regression tests when building their firmware products
We need security researchers to be able to capture their
research in a way easily consumable by OEM/BIOS
vendors
Corporate IT needs a way to know how secure the
systems they are about to deploy to 1000s of employees
Its got to be open source so everyone could see what its
testing and trust its results
Conclusions

BIOS/UEFI firmware security is an industry wide

concern. Everyone is affected. There are often
multiple issues of the same type. Some take years to
mitigate

Researchers keep finding dragons and drive

awareness. Classes of issues start to disappear.
Now we have tools use them to test your systems!

Many OEM/BIOS vendors are responsive to security

issues, stepping up to improve security of their
products (and using CHIPSEC now). HW protections
are slowly being adopted
I was told that this road would take me to
the ocean of death, and turned back
halfway. Since then crooked, round-
about, godforsaken paths stretch out
before me.
Acknowledgements

Wed like to thank the following teams or individuals for

making the BIOS and EFI firmware a bit more secure

Nick Adams, Aaron Frinzell, Sugumar Govindarajan,

Jiewen Yao, Vincent Zimmer, Bruce Monroe from Intel
Corey Kallenberg, Xeno Kovah, Rafal Wojtczuk, @snare,
Trammell Hudson, Dmytro Oleksiuk, Pedro Velaa
UEFI Forum (USRT, USST), OEMs and IBVs who suggest
solutions
References

1. Intels Advanced Threat Research Security of System Firmware

2. CHIPSEC: https://github.com/chipsec/chipsec
3. http://www.legbacore.com/Research.html
4. Low level PC attack papers by Xeno Kovah
5. MITRE Copernicus
6. Trianocore security advisories
7. UEFI Forum USRT
A little knowledge can be a dangerous
thing...

Thank You!