These are my notes for an introductory lecture covering efficient implementation as well as implementation attacks (side channels, faults). It is by far not completely covering this much more complex field, but should give a decent overview and pointers for further reading.
Author: hucktech
CacheOut: Intel Processors Data Leakage Advisory (INTEL-SA-00329, CVE-2020-0548, CVE-2020-0549)
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00329.html
https://software.intel.com/security-software-guidance/software-guidance
Acknowledgements: Intel would like to thank the following individuals for finding, reporting and coordinating these vulnerabilities to us. Intel thanks TU Graz and KU Leuven for disclosure of CVE-2020-0549. Graz University of Technology: Moritz Lipp, Michael Schwarz, Daniel Gruss. KU Leuven: Jo Van Bulck. Intel thanks VU Amsterdam, for disclosure of CVE-2020-0548 and CVE-2020-0549. VUSec group at VU Amsterdam: Stephan van Schaik, Alyssa Milburn, Sebastian Österlund, Pietro Frigo, Kaveh Razavi, Herbert Bos, Cristiano Giuffrida. Researchers from TU Graz and Ku Leuven provided Intel with a Proof of Concept (POC) in May 2019 and researchers from VU Amsterdam provided Proof of Concept (POC) in October 2019. Intel subsequently confirmed each submission demonstrates CVE-2020-0549 individually.
Linux-Surface: ACPIDumps: ACPI dumps from various Microsoft Surface devices
There’s a project which collects ACPI tables from Microsoft Surface devices. It appears to be a Linux distro for Surface, unclear how they’re being used.
https://github.com/linux-surface/acpidumps
See-also:
https://github.com/linux-surface/surface-ipts-firmware
https://github.com/linux-surface/surface-firmware
I wish OEMs had hashes for the ACPI tables they ship. I wish FWTS or CHIPSEC or someone else had some security-centric test tool that’d examine these ACPI tables for malware. There is this tool:
https://firmwaresecurity.com/2019/11/09/acpi-rootkit-scan-volatility-plugin-to-detect-acpi-rootkits/
And there’s also a collection of ACPI tables on:
https://firmwaresecurity.com/2019/12/31/acpi-tables-collection-of-acpi-tables-generated-by-linux-hardware-databases-hw-probe-tool/
Ticket #19263: Steps to hack a VirtualBox BIOS
There’s a new VirtualBox bug report, about ability of attacker to replace the Vbox firmware. The bug report had a link to a zipped DOCX file. It appears, from Oracle’s response, that they consider firmware root-of-trust a future enhancement, not a current bug. Virtualized firmware is interesting for attackers with OS root access: in that the firmware is more accessable, it is merely files on a disk, instead of flash-based, not just the files on the ESP.
This issue was initially reported to the security team, but after some discussion it was mentioned that I should open this in the public bug tracking system (seems strange to me, but…). Just for reference, follow the final conclusion from the security team:
“Admin rights give a user the power to do anything on the system. An “evil admin” is more a social component of this bug than a product’s security abilities (or its lack thereof). However, we get your point and think that the “validation/check” proposed by you may be an enhancement feature in the product. Since our team (SecAlert) only deals with security vulnerabilities in the product, we will not be able to help you on this further. You could log an enhancement request on VirtualBox’s public bug tracker: https://www.virtualbox.org/wiki/Bugtracker “
https://www.virtualbox.org/ticket/19263
https://www.virtualbox.org/attachment/ticket/19263/Steps%20to%20hack%20a%20VirtualBox%20BIOS_v2.zip
ShellTpm20CmdAct: TPM 2.0 Tools for UEFI Shell
A new set of UEFI tools for interacting with the TPM:
https://github.com/HPBirdTW/ShellTpm20CmdAct
See-also:
Verifying your system state in a secure and private way
Matthew has a new blog post on TPMs and Trusted Boot, after the recent LinuxConfAU presentation:
https://mjg59.dreamwidth.org/54203.html
https://lca2020.linux.org.au/schedule/presentation/64/
https://github.com/google/go-attestation/tree/bluetooth
Mortar: Framework to join Linux's physical security bricks (Secureboot, TPM keys, and LUKS)
Mortar is an attempt to take the headache and fragmented processes out of joining Secureboot, TPM keys, and LUKS. Through the “Mortar Model” everything on disk that is used is either encrypted, signed, or hashed. The TPM is used to effectively whitelist certain boot states. Disks are automatically unlocked once the boot sequence has been validated. This makes full-disk encryption dramatically more convenient for end-users and viable on servers (as they can automatically unlock on reboot). Mortar aims to support both TPM 1.2 (via its own implementation) and TPM 2 (via clevis). LUKS1 and LUKS2 are both supported by intelligently selecting different implementation paths based on your current setup. Mortar aims to be distribution agnostic. Initial developments are on Arch Linux and Debian Linux.
Google: Android security whitepaper
Google has a new (or updated?) white paper on Enterprise Android, with mention of Verified Boot, and other Android security features:
https://www.blog.google/products/android-enterprise/security-whitepaper/
Revsersing UEFI SMM drives on Lenovo ThinkPads
Written by Bruno – 2020-01-14
Last summer, I finally started reversing the firmware of a computer I had since quite some times: a Lenovo ThinkPad P51s.[…]The problem of calling this function from SMM is that the EFI_BOOT_SERVICES is a table of services located in the normal world. An attacker can simply change the address in the EFI_BOOT_SERVICES table and get an arbitrary call. This type of vulnerability is usually named a callout of SMRAM and they are basically equivalent to calling userland code from kernelland.[…]
https://www.synacktiv.com/posts/exploit/through-the-smm-class-and-a-vulnerability-found-there.html
Intel releases 6 new security advisories
Intel has released 6 new security advisories:
SNMP Subagent Stand-Alone Advisory for Windows INTEL-SA-00300
Chipset Device Software Advisory INTEL-SA-00306
RWC 3 for Windows Advisory INTEL-SA-00308
Processor Graphics Advisory INTEL-SA-00314
VTune Amplifier for Windows Advisory INTEL-SA-00325
DAAL Advisory INTEL-SA-00332
And a blog post about it:
https://www.intel.com/content/www/us/en/security-center/default.html
https://www.us-cert.gov/ncas/current-activity/2020/01/14/intel-releases-security-updates
GRUBKit: Skeleton project for your own GRUB-based bootkit
Grubkit is a demonstration of a very simple trick to deploy your own bootkit on a system that boots with GRUB. The trick is simply to use your own code as the init parameter to the kernel, fork, start systemd as normal and you’re done! PSTree did not detect my bootkit when I did this. Seems like a good and simple method.[…]
Haybale: Symbolic execution of LLVM IR
haybale is a general-purpose symbolic execution engine written in Rust. It operates on LLVM IR, which allows it to analyze programs written in C/C++, Rust, Swift, or any other language which compiles to LLVM IR. In this way, it may be compared to KLEE, as it has similar goals, except that haybale is written in Rust and makes some different design decisions. That said, haybale makes no claim of being at feature parity with KLEE.
Karonte: static analysis tool to detect multi-binary vulnerabilities in embedded firmware
The github project site has a link to a 3.3 gigabyte dataset hosted on Google Drive, as well…
https://github.com/ucsb-seclab/karonte
UEFI_BinDiff: UEFI modules analysing with BinDiff IDA plugin
Spring 2020 UEFI Plugfest: date/location announced
The UEFI Forum usually runs 2 plugfest events per year, one in Seattle and one in Asia. This year, it appears that it won’t be in Seattle but rather in Portland.
Where: Embassy Suites by Hilton Portland in Hillsboro, Oregon
When: March 30 – April 3, 2020
More info:
Krabs: an x86 bootloader written in Rust
Krabs is working on booting vmlinux and ELF kernels on legacy 32-bit PCs and is under the development. Krabs also aims to support only the minimal Linux boot protocol. This allows you to specify the kernel command line and manipulate the behavior of the kernel at boot time. Another feature is that in order to save space, the ELF format kernel is compressed using bzip2 before use and uses libbzip2 library for decompressing.
[…]Krabs is an experimental x86 bootloader written in Rust. Krabs can boot the ELF formatted kernel which compressed with bzip2. Krabs decompresses the bz2 image and relocate the ELF image, then boot the kernel. Some of the source code uses libbzip2 C library for decompressing, but the rest is completely Rust only.
Executing custom Option ROM on Intel NUC and persisting code in UEFI Runtime Services
In this post we’ll explore running unsigned Option ROM code on an Intel D34010WYK NUC, solely for testing purposes. We will verify that unsigned/unverified Option ROM code is not run when UEFI Secure Boot is enabled. We will demonstrate how to persist code at runtime using UEFI Runtime Services, and use a small signalling protocol to allow an unprivileged userland process to fake the contents of UEFI variables such as the SecureBoot variable.[…]
Reverse engineering UEFI firmware updater
[…]I wanted to reverse engineer the UEFI code running on my own laptop (a Lenovo Y520-15IKBN). To do this, I will first need to obtain the firmware. This should be extractable from a firmware update, so I downloaded the firmware updater from the Lenovo support site.[…]I extracted the contents of the flash ROM with UEFIExtract in the new_engine branch of UEFITool. This resulted in a folder containing over 300 PE images. One of them sounded interesting: SecureBackDoorPeim, but I think this blog post is long enough, so it may be the topic of another post.[…]
Siguza: ARM PAN (Privileged Access Never) hardware bug. In the specification
CPUs these days have a feature that prevents inadvertent memory accesses from the kernel to userland memory. Intel calls this feature “SMAP” (Supervisor Mode Access Prevention) while ARM calls it “PAN” (Privileged Access Never). Apple’s A10 chips and later have this feature,[…]
x86-sat: Basic SAT model of x86 instructions using Z3, autogenerated from Intel docs
This is a rudimentary attempt to build an autogenerated formal-ish model of x86 intrinsics by interpreting Intel’s instruction pseudocode, transforming it into a model for Z3.
https://github.com/zwegner/x86-sat
Firmware Security 
You must be logged in to post a comment.