A new Python library, Windows-centric, for UEFI variables manipulation.
Author: hucktech
OpenBMC: BMC network security audit tool
The OpenBMC project has a new security tool!
Purpose: Provide shell scripts to expose security aspects of an operational OpenBMC system from the point of view of an agent on the BMC’s management network trying to get access. The intended use is to provide information needed to audit the BMC’s interfaces, not to perform a security test. For example, the script detects if the BMC rejects TLS 1.1 and accepts TLS 1.2. The primary value the scripts provide is a starting point for what to look at, how to get the information, and where to learn more.
See the last 2 lines of current script, they are looking for some help.
Script: https://lists.ozlabs.org/pipermail/openbmc/2020-April/021186.html
More info: https://github.com/openbmc/openbmc
os-indications: tool for setting the OsIndications UEFI variable
This small utility when run will set the OsIndications UEFI variable for booting into firmware setup.
RTFM (it has a manpage!):
https://gitlab.com/JohnoKing/os-indications/-/blob/master/os-indications.8
https://gitlab.com/JohnoKing/os-indications
see-also:
https://blog.fpmurphy.com/2016/04/uefi-os-indication-variables.html
Intel blogged on OsIndications, but they changed their site and the post is apparently is no longer available:
https://software.intel.com/en-us/firmware/library/using-os-indications-uefi
NatEFI – my personal C++ UEFI application development library
Another UEFI dev environment.
This is my header library for C++17 trying to be UEFI 2.8 compliant. Can’t guarantee anything. You’re probably better off using any other header set. Also you need LLVM to build the example/test. This thing is just straight copying information from the UEFI specification, so you’re free to do anything you want to do with the header file. Just don’t take credit for creating it or something.
OWASP IoTGoat: deliberately insecure firmware created to educate software developers and security professionals with testing commonly found vulnerabilities in IoT devices
Hardware Debugging for Reverse Engineers Part 2: JTAG, SSDs and Firmware Extraction
Android Booting Shenanigans
If you are interested in the Android boot process, this is helpful:
Canadian Centre for Cyber Security: Cyber Centre Data Centre Virtualization Report: Best Practices for Data Centre Virtualization
Canada has published security guidance, which includes a bit of firmware security.
Bare-Bones-UEFI: A barebones UEFI development platform
This is a new UEFI build environment, different than GNU-EFI or EDK2’s Build or efi-clang. Based on GNU-EFI but uses Clang instead of GCC. This is about the dozenth new non-Tianocore UEFI dev environment, some of which have separate UEFI header projects: I really need to create a list. 🙂
An extremely lightweight UEFI SDK that uses a standard clang instalation to compile C directly into UEFI applications. It uses the data structures and header files from gnu-efi, but does not use any of the toolchain of gnu-efi. I’ve also included a build of edk2 to make it easy to run the UEFI applications in qemu.[…]
Analysis of the Security of UEFI BIOS Embedded Software in Modern Intel-Based Computers
By I. D. Pankov, A. S. Konoplev & A. Yu. Chernov
The paper presents an overview of current attacks on BIOS and Intel ME embedded software of modern Intel-based computers. We describe the results of the analysis of its security for system boards of basic manufacturers. We also allocate classes of attacks that make it possible to create implants whose discovery by traditional methods of searching for undeclared features becomes impossible or extremely difficult.[…]
It costs US$40, I don’t know of a freely-available version of this paper. I wish Aaron Swartz was still alive. 😦
https://link.springer.com/article/10.3103%2FS0146411619080224
Trenchboot: Secure Launch patch for x86 Linux released
The Trenchboot project focus on boot security has led to the enabling of the Linux kernel to be directly invocable by the x86 Dynamic Launch instruction(s) for establishing a Dynamic Root of Trust for Measurement (DRTM). The dynamic launch will be initiated by a boot loader with associated support added to it, for example the first targeted boot loader will be GRUB2. An integral part of establishing the DRTM involves measuring everything that is intended to be run (kernel image, initrd, etc) and everything that will configure that kernel to run (command line, boot params, etc) into specific PCRs, the DRTM PCRs (17-22), in the TPM. Another key aspect is the dynamic launch is rooted in hardware. On Intel this is done using the GETSEC instruction set provided by Intel’s TXT and the SKINIT instruction provided by AMD’s AMD-V. Information on these technologies can be readily found online.[…]
https://lkml.org/lkml/2020/3/25/982
https://github.com/trenchboot
DistributedMetricCollector: collects metrics via Redfish API and IPMI protocols
The NSFCAC (National Science Foundation Cloud and Autonomic Computing Center) has released a Python script that gathers IPMI/Redfish BMC data:
This project collects metrics from different sources including in-band (via node OS, workload manager, drivers) and out-of-band (OOB) i.e. from baseboard management controller (BMC) via Redfish API and IPMI protocols.
Intel Rocket Lake CPUs: SGX removed
Wow, I didn’t expect Intel to drop SGX support this fast…
BIOS-themed heavy metal band releases new album
Master Boot Record (MBR) means one thing, in the context of a PC system firmware. MBR is also the name of a heavy metal band. And they have a new album out, “Floppy Disk Overdrive”. The band uses many terms from BIOS and DOS. Song names include “ANSI.SYS”, “FDISK.EXE”, etc. 🙂
https://masterbootrecord.bandcamp.com/album/floppy-disk-overdrive
Second book on writing BIOS boot sector games in assembly language
Re: https://firmwaresecurity.com/2019/07/31/new-bios-book-programming-boot-sector-games/
there is a second book on BIOS boot loader games in Intel assembler:
FWTS: updated to check for Linux Kernel Lockdown patchset
FirmWare Test Suite (FWTS) has added awareness tests for the Linux Kernel Lockdown patchset. Eg:
Kernel is lockdown. Aborted.
Please unlock the kernel before you test the UEFI tests.
Make sure you disable secureboot and disable the kernel lockdown,
(by kernel parameter lockdown=None).
https://lists.ubuntu.com/archives/fwts-devel/2020-March/011725.html
U-Boot Verified Boot vulnerability: CVE-2020-10648
Excerpt from comments in part1 of patch:
When booting a FIT, if ‘bootm’ is used without a specified configuration, U-Boot will use the default one provided in the FIT. But it does not actually check that the signature is for that configuration. This means that it is possible to duplicate a configuration conf-1 to produce conf-2 (with all the signatures intact), set the default configuration to conf-2 and then boot the image. U-Boot will verify conf-2 (in fact since hashed-nodes specifies the conf-1 nodes it will effectively verify conf-1). Then it will happily boot conf-2 even though it might have a different kernel. This series corrects this problem and adds a test to verify it. It also updates fit_check_sign to allow the configuration to be specified. This vulnerability was found by Dmitry Janushkevich and Andrea Barisani of F-Secure, who also wrote the vboot_forge script included here. This is CVE-2020-10648. […]
https://lists.denx.de/pipermail/u-boot/2020-March/403409.html
No useful info yet:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-10648
https://bugs.launchpad.net/bugs/cve/2020-10648
Please use spare computing resources to fight COVID-19
[NOTE: This blog post unrelated to firmware or security.]
Please consider using any spare computing resources to help fight the COVID-19. I know of two resources, below. If you know of other resources, please leave a Comment on this blog.
https://boinc.bakerlab.org/rosetta/forum_thread.php?id=13533
https://www.worldcommunitygrid.org/forums/wcg/viewthread_thread,42191
https://foldingathome.org/start-folding/
https://foldingathome.org/2020/03/10/covid19-update/
Jonasforth: Bare-metal Forth interpreter for UEFI
The Forth programming language is not mainstream these days. But from firmware perspective: OpenFirmware was written in the Forth programming language. And now there’s a Forth compiler that targets UEFI applications. Jonas Hvid has written Jonasforth, a Forth interpreter that is a UEFI application, written in Flat Assembler (FASM). So it works on x64-based Intel UEFI/AMD (but not ARM or RISC-V or non-x64) systems.
Forth aside, this is a FASM-based UEFI application, most FASM-based UEFI apps are ‘hello world’ level, so this gives a more substantial application to study.
https://github.com/c2d7fa/jonasforth
See-also:
https://johv.dk/
SuperMicro seeks PenTester with CHIPSEC skills
It is rare to see a vendor mention “CHIPSEC” in a job posting, maybe once a quarter. Most recent one is SuperMicro.
Supermicro is looking for a Software QA Engineer focusing on Security Penetration Testers with either Firmware, Network and/or Web Application penetration testing experience. You will have to be creative and come with original ideas to build infrastructure for automation and figure out on how to break the software & firmware. […]
https://jobs.supermicro.com/job/San-Jose-Software-QA-Engineer-Cali/638885500/
Firmware Security 
You must be logged in to post a comment.