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
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:
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.[…]
Two new tools: dumpACPITables.py and scanACPITables.py:
[…] 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.[…]
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.[…]
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  but it was never upstreamed. Linaro started work on LUV (which includes CHIPSEC) but hasn’t finished the work. 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.
A couple of weeks ago I presented a workshop about firmware extraction at the conference Hack.lu 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.[…]
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. 🙂
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.
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
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:
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. […]