Bootloader and Secure Boot attacks

Bootloader and Secure Boot attacks

TL;DR: Secure Boot establishes a chain of trust from immutable ROM through bootloader, kernel, and user-space. Each stage verifies the next via signature checks rooted in OEM keys. Bypasses come from: leaked/sold OEM keys, validation bugs in early-boot code, downgrade to a vulnerable signed component (LogoFAIL, BlackLotus, PKfail), or hardware-level fault injection. Companion to pkfail-uefi-secureboot-bypass and uart-jtag-debug.

Why bootloader / Secure Boot matters

  • Secure Boot is the foundation for every higher security property: kernel integrity, TPM measurements, BitLocker, code integrity.
  • A bypass means persistent, kernel-level malware that survives reinstall.
  • Hardware roots of trust are baked into ROM; if a bug exists there, no firmware update can fix it.
  • The class spans Windows PCs (UEFI), Macs (BootROM), iPhones, Android, embedded devices, game consoles, automotive ECUs.

The chain of trust

Generic chain:

1
2
3
4
5
6

ROM bootloader (immutable)
  → verifies → 1st-stage bootloader (in flash)
    → verifies → 2nd-stage bootloader (or kernel signature checker)
      → verifies → kernel
        → verifies → init / user space
          → verifies → application code

Each stage holds (or has access to) the public key of the next stage’s signer. Verification is per-stage.

If any stage doesn’t verify, or verifies with a flawed algorithm, or trusts a key that shouldn’t be trusted, the chain is broken from that point downward.

Class 1 — Leaked OEM keys

If a vendor’s signing key leaks (insider, breach, supply chain), attackers can sign their own boot components that the chain trusts.

Historical:

  • PKfail (2024) — see pkfail-uefi-secureboot-bypass. Several OEMs (Lenovo, others) shipped UEFI with test Platform Keys that were publicly known. Anyone with the private key (publicly leaked) can sign UEFI for those systems.
  • MSI motherboard 2023 — signing key leaked through repository compromise.

Defence: per-device keys, hardware-protected key storage (HSM), key rotation. Hard to do retroactively.

Class 2 — Validation logic bugs

Pre-boot environments are constrained C code with limited testing. Bugs include:

  • Buffer overflow in parser of bootable media (UEFI partition table, ISO9660, NTFS).
  • Integer overflow in length checks.
  • TOCTOU between hash-then-verify and actual load.
  • Signature verification skipped under specific configurations (UEFI Compatibility Support Module, Apple boot policy edge cases).
  • Hash collision with deprecated algorithms (MD5, SHA-1 historically).

Examples:

  • LogoFAIL (2023) — vulnerabilities in UEFI logo image parsers (BMP/PNG/JPG). UEFI loads a vendor logo at boot; the parser had buffer overflows. Attacker replaces logo with a crafted image; Secure Boot stays “valid” because the image is signed-data, but exploitation runs arbitrary code pre-OS.
  • BlackLotus (2022) — UEFI bootkit; exploits Baton Drop (CVE-2022-21894) to bypass Secure Boot on Windows.
  • BootHole (2020) — GRUB2 buffer overflow.

Class 3 — Downgrade to vulnerable signed component

Even if a vendor patches a Secure Boot bypass, the old signed component is still signed. Unless the platform actively revokes via DBX (the UEFI revocation database), an attacker can downgrade to the buggy version.

Microsoft’s DBX update process is slow; many systems run with stale DBX. BlackLotus benefited from this for months.

Defence: DBX updates, “secure boot advanced targeting” (SBAT) in modern Linux to revoke specific versions.

Class 4 — Hardware fault injection / glitching

Bypasses at the silicon level:

  • Voltage glitching — drop VCC for nanoseconds at a precise moment to skip a verification instruction.
  • Clock glitching — same idea with clock signal.
  • EMFI (electromagnetic fault injection) — induce single-bit flips.
  • Laser fault injection — targeted memory cell flips.

Used historically against:

  • Game consoles (PS3, Xbox 360, Nintendo Switch).
  • Microcontrollers (STM32 family, NXP).
  • Set-top boxes / cable modems.

Tools: ChipWhisperer, Riscure Spider/Inspector (commercial), homemade glitching rigs.

Class 5 — Implementation downgrades

Some Secure Boot implementations have “developer mode” or “engineering” modes that disable verification.

  • Pixel devices have unlockable bootloader (user choice, but attacker can present “unlocked” warning to user).
  • Some Android OEM bootloaders accept fastboot commands that flash without verification when in a certain physical state.
  • macOS Recovery Mode has specific properties; some pre-T2 Macs allowed disabling SIP via NVRAM modification.

Class 6 — TPM PCR manipulation

Secure Boot measures itself into TPM PCRs. Code that depends on the measurements (BitLocker volume unlock, Linux Clevis) checks the PCR values.

Bypasses:

  • PCR replay during boot — manipulate which PCRs are extended.
  • TPM bus sniffing — read keys as they transit the TPM bus (research by Pulse Security, others).
  • TPM 1.2 vs 2.0 — older TPMs have limitations.

Workflow to study

  1. PC UEFI — binwalk extract UEFI image; UEFITool to inspect. Look for the Platform Key db / kek / dbx.
  2. DBX state — fwupd on Linux, PowerShell Get-SecureBootUEFI dbx on Windows.
  3. Logical bypass — research disclosed CVEs (PKfail, LogoFAIL, BlackLotus, BootHole) and reproduce in a VM.
  4. Hardware — start with ChipWhisperer Lite + a target STM32 board; reproduce a known voltage-glitch attack.

Defensive baseline

  • Update UEFI firmware regularly.
  • Apply DBX updates.
  • Use SBAT for Linux components.
  • Enable BitLocker / FileVault with TPM-bound keys.
  • Use vendor-managed certificate stores when possible.
  • For embedded: per-device keys, HSMs.
  • For high-security: anti-tamper enclosures, mesh sensors.

Workflow to study (Windows lab)

  1. Set up a Windows 11 VM with Secure Boot enabled.
  2. Download BlackLotus / pre-patch image.
  3. Use Microsoft’s SecureBoot toolkit to inspect dbx.
  4. Verify which signed components remain valid for downgrade.
  5. Apply MS-distributed DBX update; observe revocation.

References