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;-)
Reference
[1] coreboot