ANSSI: Hardware security requirements for x86 platforms (and bootable CHIPSEC thumbdrive)

This guide presents some security features and configuration options applying to hardware devices. These features are defined in the form of requirements and can apply to a provider of these hardware configurations. The intended goal is to enforce security of new hardware acquired by an IT department. Each requirement is followed by a security objective specifying the goal.[…]

Provided tools can be used to build two bootable USB keys:

* the first around the chipsec tool edited by Intel, integrated in a Debian live distribution, which can be used to check the platform configuration registers.

* the second one is built around the keytool.efi binary which can be use to inspect and modify the SecureBoot key list. The key can be used to check that the platform will accept new, custom SecureBoot keys

AMD: AGESA update (on Reddit)

I often see news about AMD AGESA in the news, often starting on Gamer web sites talking about gamer-centric boxes. I wish there was a primary source of this data, but it appears that AMD tells it’s vendors and the vendors tell the media about the updates, and there was no direct AMD source of this information. At least that’s what I thought until a few days ago. The “AMD Official” user on Reddit has posted a status update on the next AGESA release:

An Update on the AM4 Platform & AGESA 1004

AMD has recently released a new AGESA to manufacturers, version 1004. With over 150 changes, this is a significant milestone release in the development of the AM4 platform. We wanted to share some background in support of our release and particularly in advance of the AMD Ryzen 9 3950X processor launch on Nov. 25th.[…]

Let’s hope there are regular updates on AGESA on this Reddit site:

More info:

Intel’s equivalent to AMD AGESA is FSP. By comparision, there is a bit more metadata to see what’s happening with FSP, I wish AMD had similar resources for AGESA:

18 new security advisories from Intel

Latest batch since October.

INTEL-SA-00313: Intel® BMC Advisory
INTEL-SA-00309: Nuvoton* CIR Driver for Windows® 8 for Intel® NUC Advisory
INTEL-SA-00293: 2019.2 IPU – Intel® SGX Advisory
INTEL-SA-00288: Intel® PROSet/Wireless WiFi Software Security Advisory
INTEL-SA-00287: Intel® WIFI Drivers and Intel® PROSet/Wireless WiFi Software extension DLL Advisory
INTEL-SA-00280: 2019.2 IPU – UEFI Advisory
INTEL-SA-00271: 2019.2 IPU – Intel® Xeon® Scalable Processors Voltage Setting Modulation Advisory
INTEL-SA-00270: 2019.2 IPU – TSX Asynchronous Abort Advisory
INTEL-SA-00260: 2019.2 IPU – Intel® Processor Graphics Update Advisory
INTEL-SA-00255: 2019.2 IPU – Intel® Ethernet 700 Series Controllers Advisory
INTEL-SA-00254: 2019.2 IPU – Intel® Processor Graphics SMM Advisory
INTEL-SA-00242: 2019.2 IPU – Intel® Graphics Driver for Windows* Advisory
INTEL-SA-00241: 2019.2 IPU – Intel® CSME, Intel® SPS, Intel® TXE, Intel® AMT, Intel® PTT and Intel® DAL Advisory
INTEL-SA-00240: 2019.2 IPU – Intel® Processor Security Advisory
INTEL-SA-00220: 2019.2 IPU – Intel® SGX and TXT Advisory
INTEL-SA-00219: 2019.2 IPU – Intel® SGX with Intel® Processor Graphics Update Advisory
INTEL-SA-00210: 2019.2 IPU – Intel® Processor Machine Check Error Advisory
INTEL-SA-00164: 2019.2 IPU – Intel® TXT Advisory

I think I’ll stop looking for updates on this site, no changes since January. I think the security team doesn’t update it and the marketing team has forgotten about it:

No changes yet for the above security issues on the Tianocore advisories:

I may’ve missed them, but I don’t see any new CHIPSEC detections for some of above issues:

EFI_DXE-Emulator: EFI DXE Emulator and Interactive Debugger!

Pedro Vilaca has created EFI DXE Emulator. It is an EFI DXE phase binaries emulator based on Unicorn. It allows to run EFI DXE binaries inside a Unicorn virtual nachine with a basic interactive debugger that allows to step and interact with the EFI code. It works by implementing basic EFI Boot and Runtime services. Not every service is yet implemented, such as services to load and locate other binaries. This can be done with extra work, since the core code to load binaries already exists, although it needs to be modularized. Can be used to easier reverse some EFI binaries that don’t interact with hardware or graphical EFI interface. The debugger is still pretty basic but allows to view and modify registers and memory, step into calls or over them, and breakpoints. […] Even with all its limitations this is a pretty useful tool for reversing some EFI binaries, improving a lot the reverse engineering process from a static analysis only (for us who don’t have 6k JTAG based EFI debuggers). It’s also a nice showcase of Unicorn potential and limitations. With further development it could be expanded to fuzzing and vulnerability discovery in firmware world.[…] AMD flash dumping tool

This AMD flash dumping tool is part of Divination, a Windows-centric tool that reminds me of RWEverything and the CHIPSEC kernel-mode drivers, and similar interfaces:

ACPI-rootkit-scan: volatility plugin to detect ACPI rootkits

Two new tools: and

[…] The plugin is able to extract the ACPI tables from a memory dump in raw and aml format (for description of the parameters see “-h” option in volatility). The files are extracted to a special folder e.g. ./dumpedTables/ and sub-folders are created for every base pointer (RSDP) found in the specified memory region.[…]

CVE-2019-13103: U-Boot, Amazon Kindle, Embedded Devices Open to Code-Execution

Threatpost excerpt:
Flaws in Das U-Boot affect third-party hardware that uses the universal bootloader as an underlying component. Multiple vulnerabilities have been found in Das U-Boot, a universal bootloader commonly used in embedded devices like Amazon Kindles, ARM Chromebooks and networking hardware. The bugs could allow attackers to gain full control of an impacted device’s CPU and modify anything they choose. Researchers at ForAllSecure found the flaws in U-Boot’s file system drivers. They include a recursive stack overflow in the DOS partition parser, a pair of buffer-overflows in ext4 and a double-free memory corruption flaw in ext4. They open the door to denial-of-service attacks, device takeover and code-execution.[…] ForAllSecure also found five low-severity divide-by-zero bugs, triggered by invalid extended file systems. U-Boot patched the bugs as of its v. 2019.10 release – but devices are likely still vulnerable given that the update process is controlled by the vendor of the device rather than U-Boot itself.[…]

UEFI Forum: How to Create a Secure Development Lifecycle for Firmware

The UEFI Forum’s recent webinar is now archived and available for on-demand viewing:

I hope the UEFI Forum also starts doing some webinars for downstream consumers of UEFI firmware (eg: enterprise blue team defenders), nost just upstream firmware engineers.

I hope the UEFI Forum starts to address security a bit better than indirectly referencing CHIPSEC. Current UEFI Forum tests (SCTs) are basically useless when it comes to security. Intel CHIPSEC only works on INTEL processors, not AMD nor ARM processors, so any CHIPSEC reference for UEFI firmware security is USE:LESS for non-Intel systems. There was a partial ARM port [1] but it was never upstreamed. Linaro started work on LUV (which includes CHIPSEC) but hasn’t finished the work[2]. As I understand things, AMD won’t be able to port current CHIPSEC to AMD since current CHIPSEC interface works with public Intel interfaces but would require non-public interfaces to make it work for AMD. Unless something changes, I don’t see how CHIPSEC will ever work on non-Intel platforms. You’d think ARM and/or AMD, or one of their larger customers, would have a vested interest in fixing this problem. 😦 Before you buy a new UEFI system, ask if you have security tools to audit that system, starting with if those tools are ported to that CPU.



Mojo_Thor: Apple EFI malware updated for T2

Regarding this Apple EFI malware:

most code activity was in 2017, but there’ve been a few changes in the last few weeks, mostly related to the new Apple T2 processor:

Apple security readers: it looks like you still need to follow-up with author, see the readme.

PS: The author is also the author of efivalidate:

OWASP: Firmware Security Testing Methodology (and: EmbedOS – Embedded security testing VM)

Note there is a companion VM:

Hmm, I can only find the PDF version of this content, no HTML/wiki version… See-also:

Google announces OpenTitan: Open source silicon root of trust

OpenTitan logo

Intro to hardware hacking: firmware extraction

A couple of weeks ago I presented a workshop about firmware extraction at the conference in Luxembourg. The goal of this workshop was to provide a very basic knowledge of how to dump a firmware from a device, to allow people to start their own project. Our targets here are two small routers.[…]

Alas, I don’t see this workshop in the list of available videos for this event:

CyberSecurity Evaluation Tool (CSET): tiny reference to NIST 147

US DHS has released version 9.2 of CSET, their CyberSecurity Eval Tool, and it has a one reference to NIST 147 (BIOS security) …but I don’t see that the tool does anything with firmware security. The same SQL table that references NIST 147 also references many other specs.

And it might be Windows-centric (at least only has Windows releases, unsure if the source will build on other OSes, it appears to be tied to IIS and ASP.NET). I enjoy the screenshots of how to use the Windows intaller showing to accept their UNSIGNED code. 🙂

Microsoft: Device Firmware Management Configuration Interface (DFCI)

This is an abstract from a Microsoft Ignite session, taking place November 4-8 in Florida:

Managing Surface UEFI BIOS settings with Microsoft Intune
Karan Dhillon, Daniel Gerrity

Introducing Device Firmware Management Configuration Interface (DFCI) as managed through Microsoft Intune for Surface devices. Now you can lock down the BIOS menu as part of Windows Autopilot device setup and manage BIOS settings for all your devices from the Microsoft 365 Device Management Admin Center. Learn how to add DFCI management to your Autopilot deployment, configure settings for boot options and hardware restrictions, and retire devices from DFCI management.


Tianocore Edk2 PyTool Library (edk2toollib): Python library package that supports UEFI dev

There’s a relatively-new UEFI library, which appears to have been created by Microsoft Project Mu, and later upstreamed to Tianocore. There’s a related extension project as well. This code would be useful for tools analyzing UEFI binaries and source projects.

Tianocore Edk2 PyTool Library (edk2toollib) is a Tianocore maintained project consisting of a python library supporting UEFI firmware development. This package’s intent is to provide an easy way to organize and share python code to facilitate reuse across environments, tools, and scripts. […] The package contains classes and modules that can be used as the building blocks of tools that are relevant to UEFI firmware developers. […] Examples:

  • File parsers for edk2 specific file types. These parse the file and provide an object for interacting with the content.
  • UEFI specific services for encoding/decoding binary structures.
  • UEFI defined values and interfaces for usage in python
  • Python wrappers for other system cli tools ( signtool, catalog file generation, inf file generation, etc)
  • Python utilities to provide consistent logging, command invocation, path resolution, etc

Debian support of UEFI Secure Boot

Steve McIntyre has posted a long message to the debian-efi mailing list, with a summary of the “Secure Boot BoF” from the last Debian Conference earlier this year(DebConf19), with a good summary of how Debian implements UEFI Secure Boot:

More info:

Clang Build Analyzer: Clang build analysis tool

So! A while ago I worked on adding -ftime-trace support for Clang. That landed and shipped in Clang 9.0 in September of 2019, so \(^O^)/ Looks like it will also be coming to Sony development tools soon (see SN Systems blog post). All that is good, but it works on one compiled file at a time. If you know which source files are problematic in your whole build, then great. But what if you don’t, and just want to see things like “which headers are most expensive to include across whole codebase”? I built a little tool just for that: Clang Build Analyzer. […]

Purism: Anti-interdiction Services

Purism, a Linux OEM, has a new blog post describing their anti-interdiction service and a how it works with their bootloader: