Skip to content

smm-research.md

Latest commit

 

History

History
180 lines (127 loc) · 6.6 KB

smm-research.md

File metadata and controls

180 lines (127 loc) · 6.6 KB
Raw

System Management Mode — Research Reference

Overview

System Management Mode (SMM) is the x86/x64 processor's highest-privilege execution mode. SMM exploitation provides the most persistent and least-detectable form of PC firmware compromise. This document covers the SMM threat model, exploitation prerequisites, and detection approaches.

No working exploit code is included. This is a reference for threat modeling and defensive planning.

SMM Architecture

Execution Context

SMM is triggered by a System Management Interrupt (SMI). The CPU:

  1. Saves the current execution context to SMRAM
  2. Transfers execution to the SMM handler at the SMRAM base address
  3. Executes at the highest CPU privilege level (Ring -2)
  4. Returns to the interrupted context when the SMM handler executes RSM

SMM execution is:

  • Completely invisible to the OS: The OS cannot observe SMM execution; time appears to stop from the OS's perspective
  • Invisible to hypervisors: Type-2 hypervisors (Hyper-V, VMware on bare metal) cannot intercept SMM (Type-1 bare-metal hypervisors with hardware SMM virtualization can observe SMM via VM_EXITS, but most enterprises do not use this)
  • Invisible to EDR: No EDR agent or security product has visibility into SMM execution

SMRAM Protection

SMRAM is protected by the chipset via the TSEG (Top Segment) and SMRAM_LOCK bit in the chipset control registers. Once the firmware sets SMRAM_LOCK, the OS and applications cannot read or write SMRAM directly.

However, vulnerabilities in the UEFI firmware's SMM handlers provide a path to write attacker-controlled data into SMRAM via the legitimate SMI dispatch mechanism.

Attack Prerequisites

Kernel-Level Access (Required)

Triggering SMI from software requires kernel-level access:

  • On Linux: writing to the SMI port (/dev/port, port 0xB2) requires iopl(3) or direct /dev/mem access, both of which require root
  • On Windows: writing to port 0xB2 requires a kernel driver or a UEFI-level tool like RWEverything (which has been used in BYOVD attacks)
  • Physical access: some systems expose the SMI trigger via a button or diagnostic USB interface, but this is uncommon in enterprise hardware

No Kernel-Level Access Path

For systems with Secure Boot + HVCI + Driver Signature Enforcement, an attacker cannot load an unsigned kernel driver to invoke SMI. BYOVD (Bring Your Own Vulnerable Driver) circumvents this by using a signed-but-vulnerable legitimate driver to proxy the SMI trigger.

The tools/byovd/ module covers BYOVD driver candidates.

SMM Exploitation Techniques

Buffer Overflow (CVE-2025-4275 class)

Covered in hydroph0bia-secure-boot.md. The primary technique for SMM code execution: supply an oversized buffer to an SMM handler, overflow into adjacent SMRAM code/data, overwrite a function pointer, achieve arbitrary SMM code execution.

TOCTOU (Time-of-Check Time-of-Use)

SMM handlers that read a value from the communication buffer and then use it later are vulnerable to TOCTOU attacks: the OS-controlled memory can be modified between the time the SMM handler reads it (check) and the time it acts on the value (use). SMM handlers must copy communication buffer data to SMRAM before validation, not use it directly from the OS-provided buffer. Handlers that do not follow this pattern are vulnerable.

Unchecked Pointer Dereference

SMM handlers that dereference pointers supplied by the OS caller without verifying the pointer targets SMRAM-accessible memory can be caused to access arbitrary memory (including SMRAM itself) by supplying crafted pointer values.

Post-SMM Objectives

Disabling Secure Boot

From SMM, an attacker can modify the SecureBoot, SetupMode, and PKDefault NVRAM variables via the SMM variable services. Setting SetupMode=1 and clearing the PK (Platform Key) disables Secure Boot enforcement without going through the normal authenticated variable update process.

This allows subsequent reboots to execute unsigned bootloaders and OS kernels.

Installing a DXE Implant

With Secure Boot disabled, the attacker can write an unsigned UEFI DXE driver to the EFI System Partition. DXE drivers run before the OS, persist across OS reinstall, and can:

  • Modify the OS bootloader before it loads
  • Install a UEFI rootkit that intercepts OS initialization
  • Patch kernel code before the OS security mechanisms activate

Flashing SPI

On systems where the SPI flash controller is not write-protected from SMM context, the SMM code can directly overwrite firmware regions. This provides even deeper persistence — the implant survives not just OS reinstall but also EFI partition formatting.

Most enterprise-grade systems write-protect the SPI flash controller from both OS and SMM context after initial boot (Platform Controller Hub protected range registers). However, misconfigured or older systems may leave flash writable from SMM.

Detection Approaches

SMM execution itself is not observable from the OS. Detection relies on:

Pre-Compromise: Secure Boot Chain Integrity

Monitor for Secure Boot state changes:

  • Windows: Event 4670/4671 in the Security log for NVRAM variable writes
  • Linux: mokutil --sb-state; alert if Secure Boot is disabled
  • SIEM: Alert on any NVRAM variable write for SecureBoot, PK, KEK, db, dbx

Pre-Compromise: Firmware Integrity Measurement

TPM-based Secure Boot measures each firmware component in PCR[0] through PCR[7]. A firmware modification causes PCR values to change. Periodically compare TPM PCR values against a known-good baseline to detect firmware modification.

Tools: tpm2-tools, tpm2_pcrread

SMM Lock Verification

Verify that SMRAM is properly locked at boot via:

# Linux: chipsec
python chipsec_main.py -m common.smm
python chipsec_main.py -m common.smrr

A FAIL result from chipsec's SMM check indicates that SMRAM lock bits are not properly set — a misconfiguration that lowers the exploitation bar.

ESP File System Monitoring

Monitor the EFI System Partition for unauthorized file modifications:

# Linux
inotifywait -m -r /boot/efi

# Windows (via file system audit policy)
auditpol /set /subcategory:"File System" /success:enable /failure:enable
# Then set audit ACE on X:\EFI\ (where X: is the EFI partition)

References

  • Intel SDM, Volume 3A, Chapter 34: System Management Mode
  • Binarly Research: multiple SMM vulnerability publications (2022–2025)
  • Eclypsium: "Firmware Security at Scale" reports
  • Chipsec: github.com/chipsec/chipsec
  • NIST SP 800-147: BIOS Protection Guidelines
  • NIST SP 800-147B: BIOS Protection Guidelines for Servers