We are "patient" zero, so we hardened ourselves!

Jul 31, 2017 - 2 minute read - Research

Firmware auditing with CHIPSEC

Install the prerequisite packages:

Or if you are using PaX/Grsecurity 4.9.x:

Install the CHIPSEC

Firmware security checklist based on CHIPSEC

According to the firmware security training from McAfee Advanced Threat Research. CHIPSEC modules perform a couple checks for the auditing purposes:

Issue CHIPSEC Module References
SMRAM Locking common.smm CanSecWest 2006
BIOS Keyboard Buffer Sanitization common.bios_kbrd_buffer DEFCON 16
SMRR Configuration common.smrr ITL 2009, CanSecWest 2009
BIOS Protection common.bios_wp BlackHat USA 2009, CanSecWest 2013, Black Hat 2013, NoSuchCon 2013
SPI Controller Locking common.spi_lock Flashrom, Copernicus
BIOS Interface Locking common.bios_ts PoC 2007
Secure Boot variables with keys and configuration are protected common.secureboot.variables UEFI 2.4 Spec , All Your Boot Are Belong To Us ( here & here)
Memory remapping attack remap Preventing and Detecting Xen Hypervisor Subversions
DMA attack against SMRAM smm_dma Programmed I/O accesses: a threat to VMM?, System Management Mode Design and Security Issues
SMI suppression attack common.bios_smi Setup for Failure: Defeating Secure Boot
Access permissions to SPI flash descriptor common.spi_desc Flashrom
Access permissions to UEFI variables defined in UEFI Spec common.uefi.access_uefispec UEFI 2.4 Spec
Module to detect PE/TE Header Confusion Vulnerability tools.secureboot.te All Your Boot Are Belong To Us
Module to detect SMI input pointer validation vulnerabilities tool.smm.smm_ptr CanSecWest 2015
SPI Flash Descriptor Security Override Pin-Strap common.spi_fdopss FLOCKDN
IA32 Feature Control Lock common.ia32cfg IA32_Feature_Control MSR lock bit
Protected RTC memory locations common.rtclock ??
S3 Resume Boot-Script Protections common.uefi.s3bootscript ??
Host Bridge Memory Map Locks memconfig PCI cfg

Firmware whitelist management for the data center

Generate the firmware whitelists:

Check if the firmware is on the whitelist:

Hardening the coreboot

coreboot is a popular free/libre implementation of firmware for diverse hardware platforms. We’ve been using it on x86 and RISC-V for a while. The philosophy of coreboot might assumed that the user know the risk while they enjoying their freedom( “super developer” mode?) because coreboot won’t enable some security mechanism at boot time by default:

We shouldn’t use the same method to assess the security risk of coreboot with “traditional” UEFI implementations by vendors. Because there are some differences, e.g: coreboot doesn’t have some EFI runtime features and the SMM code size is usually smaller than UEFI. But there are some exploitable bugs that we should aware of. Some security mechanism can be enabled at runtime, while other has to do it manually. Thanks to CHIPSEC’s hardware abstraction layer, it’s easy to implement the script of enablement of security mechanism, which get rid of us from those 0ld hard coded days;-)


[1] coreboot

[2] Info about firmware security