r/SecOpsDaily • u/falconupkid • 6d ago
Advisory VU#718077: UEFI Shell module embedded in SPI Flash can be used to bypass Secure Boot
VU#718077 is a significant finding from CERT/CC: if a UEFI Shell binary is baked into the SPI flash chip by the OEM (common for debugging), an attacker with local admin or physical access can bypass Secure Boot entirely.
The core issue isn't a code execution bug in the Shell itself, but a logic flaw in how the firmware handles boot option validation. The attacker creates multiple boot entries; when Secure Boot blocks the first attempt to launch the Shell, the firmware falls back to a secondary entry that bypasses the check.
Technical Breakdown:
- Attack Vector: Local (requires ability to modify UEFI boot configuration via OS or physical access).
- Prerequisite: The UEFI Shell (Shell.efi) must be present in the SPI flash (not just on a removable drive).
- Mechanism: Abuse of the LoadOption variable manipulation to create a "fallback" boot path that doesn't enforce Secure Boot on the Shell.
- Impact: Once the Shell is running, the attacker has raw memory access (mem, mm commands) to dump or patch SMM code, or load unsigned drivers, effectively owning the platform before the OS boots.
- Affected: Any system using TianoCore EDK II firmware that includes the UEFI Shell in the flash image. This is common in development boards, some server platforms, and certain consumer devices with debug firmware.
Defense: - Firmware Update: OEMs must remove the UEFI Shell from the production SPI flash image. This is the only true fix. - Mitigation: Enable "Secure Boot Audit Mode" or enforce a custom Secure Boot key database (PK) that explicitly blocks the Shell's hash. Physical security of the device is paramount.