Researchers discovered that signed UEFI shells containing an “mm” memory-modify command can be used to bypass Secure Boot on many systems by overwriting the Security Architectural Protocol handler, enabling pre-OS arbitrary code execution and persistence. Framework-distributed signed shells affecting roughly 200k devices were found vulnerable, and mitigations include DBX revocations, firmware updates, and BIOS/UEFI configuration changes. #mm #gSecurity2
Keypoints
- Signed UEFI shells distributed and trusted via Microsoft and OEM certificates can include powerful memory-manipulation commands (mm) that run pre-OS with elevated privileges.
- The mm command allows direct read/write access to system memory, enabling attackers to overwrite the Security Architectural Protocol pointer (gSecurity2) and disable Secure Boot verification.
- Eclypsium researchers tested Framework-supplied shells, confirmed mm capability in signed binaries, and disclosed findings to Framework; roughly 200k Framework devices were affected.
- Attack flow: locate gSecurity2 in memory via shell commands, use mm to patch the security handler to NULL or always-success, load arbitrary unsigned UEFI modules, and persist via startup.nsh.
- Real-world abuse is already observed in gaming cheat markets and by malware families (e.g., HybridPetya) and bootkits (BlackLotus, Bootkitty) leveraging pre-OS techniques.
- Mitigations include DBX revocations/updates to blacklist vulnerable shells, firmware updates from vendors, BIOS/UEFI passwords, custom Secure Boot keys, and firmware scanning/analysis.
- Long-term risk highlights a supply-chain trust problem: digital signatures alone can’t guarantee safety if signed tools expose dangerous functionality.
MITRE Techniques
- [T1562] Impair Defenses – Attackers overwrite the Security Architectural Protocol handler (gSecurity2) using the mm command to disable Secure Boot verification (“mm 0x[target_address] 0x00000000 -w 8 -MEM” writes zeros to the security handler pointer).
- [T1105] Ingress Tool Transfer – With Secure Boot verification bypassed, attackers load arbitrary UEFI modules or bootkits into pre-OS environment (“the system will load and execute any UEFI module, signed or unsigned”).
- [T1547.001] Boot or Logon Autostart Execution: Bootloader Modification – Attack persists by placing mm exploit commands in startup.nsh so the bypass runs automatically on each boot (“placing the attack commands in a startup.nsh script, the bypass executes automatically on every boot”).
- [T1204.002] User Execution: Malicious File – Legitimate-signed UEFI shells distributed by vendors act as delivery for the mm capability, enabling misuse despite valid signatures (“signed UEFI shells… distributed by Framework… are signed to be authorized to run according to the DB included on Framework systems”).
Indicators of Compromise
- [File Hashes] Vulnerable signed UEFI shell binaries – examples: Bootx64.efi from Framework_Laptop_13_12th_Gen and Framework_Laptop_13_13th_Gen (file names shown: Bootx64.efi), and other Framework bootx64.efi images.
- [File Names] UEFI shell files and scripts – examples: bootx64.efi, startup.nsh (startup.nsh can contain mm commands to persist the bypass).
- [Configuration/DB Entries] Secure Boot DB/DBX entries – context: DB entries include certificates used to validate shells and DBX updates used to revoke/block vulnerable shells (Framework Secure Boot DB contained certificates used to verify shells; DBX revocations planned).
- [Commands/Artifacts] mm command usage – examples: “mm 0x[target_address] 0x00000000 -w 8 -MEM”, “Shell> mm 80 -w 4 -IO” indicating memory write operations via UEFI shell.
Read more: https://eclypsium.com/blog/bombshell-the-signed-backdoor-hiding-in-plain-sight-on-framework-devices/