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/982https://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.

https://github.com/nsfcac/DistributedMetricCollector

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:

Paperback:
http://www.lulu.com/shop/oscar-toledo-gutierrez/more-boot-sector-games/paperback/product-24462035.html

Hardcover:
http://www.lulu.com/shop/oscar-toledo-gutierrez/more-boot-sector-games/hardcover/product-24462029.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/

https://en.wikipedia.org/wiki/Forth_(programming_language)

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/

UEFI Flappy Bird game(s)

Re: https://firmwaresecurity.com/2016/12/28/boot2flappy-flappy-bird-port-to-uefi-in-assembly/

points to this version of the game:

https://github.com/fabianishere/boot2flappy

There are either 2 UEFI Flappy Bird projects:

But I notice on Gitlab that there’s another active UEFI Flappy Bird game:

https://gitlab.com/square.wheel/FlappyBird-UEFI-QEMU/-/tree/master/

which appears to replace:

https://github.com/hymen81/UEFI-Game-FlappyBirdy

If I had a bit more time to spend on UEFI games today, I’d check if these two active codebases are the same, or two separate UEFI Flappy Birds.

Intel releases 9 security advisories

9 new security advisories from Intel, including the LVI one:

and a blog post about them:
https://blogs.intel.com/technology/2020/03/ipas-security-advisories-for-march-2020/

INTEL-SA-00354: Intel® Smart Sound Technology Advisory
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00354.html

INTEL-SA-00352: BlueZ Advisory
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00352.html

INTEL-SA-00349: Intel® MAX® 10 FPGA Advisory
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00349.html

INTEL-SA-00343: Intel® NUC Firmware Advisory
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00343.html

INTEL-SA-00334: Intel® Processors Load Value Injection Advisory
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00334.html

INTEL-SA-00330: Snoop Assisted L1D Sampling Advisory
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00330.html

INTEL-SA-00326: Intel® Optane™ DC Persistent Memory Module Management Software Advisory
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00326.html

INTEL-SA-00319: Intel® FPGA Programmable Acceleration Card N3000 Advisory
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00319.html

INTEL-SA-00315: Intel® Graphics Drivers Advisory
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00315.html

LVI – Hijacking Transient Execution with Load Value Injection (INTEL-SA-00334)

Load Value Injection (LVI): a “transient-execution attack” — it even has a movie trailer:

https://lviattack.eu/

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00334.html

Take A Way: Exploring the Security Implications of AMD’s Cache Way Predictors

Link in below Tweet:

Moritz Lipp, Arthur Perais, Vedad Hadžić, Clémentine Maurice, Michael Schwarz, Daniel Gruss

To optimize the energy consumption and performance of their CPUs, AMD introduced a way predictor for the L1-data (L1D) cache to predict in which cache way a certain address is located. Consequently, only this way is accessed, significantly reducing the power consumption of the processor. In this paper, we are the first to exploit the cache way predictor. We reverse-engineered AMD’s L1D cache way predictor in microarchitectures from 2011 to 2019, resulting in two new attack techniques. With Collide+Probe, an attacker can monitor a victim’s memory accesses without knowledge of physical addresses or shared memory when time-sharing a logical core. With Load+Reload, we exploit the way predictor to obtain highly-accurate memory-access traces of victims on the same physical core. While Load+Reload relies on shared memory, it does not invalidate the cache line, allowing stealthier attacks that do not induce any last-level-cache evictions. We evaluate our new side channel in different attack scenarios. We demonstrate a covert channel with up to 588.9 kB/s, which we also use in a Spectre attack to exfiltrate secret data from the kernel. Furthermore, we present a key-recovery attack from a vulnerable cryptographic implementation. We also show an entropy-reducing attack on ASLR of the kernel of a fully patched Linux system, the hypervisor, and our own address space from JavaScript. Finally, we propose countermeasures in software and hardware mitigating the presented attacks.

Azeria Labs: Android TrustZone exploitation part 2 released

Azeria Labs has released the 2nd installment of their TEE training:

Positive Technologies: Intel x86 Root of Trust: loss of trust

[…]A vulnerability has been found in the ROM of the Intel Converged Security and Management Engine (CSME). This vulnerability jeopardizes everything Intel has done to build the root of trust and lay a solid security foundation on the company’s platforms. The problem is not only that it is impossible to fix firmware errors that are hard-coded in the Mask ROM of microprocessors and chipsets. The larger worry is that, because this vulnerability allows a compromise at the hardware level, it destroys the chain of trust for the platform as a whole.[…]

https://blog.ptsecurity.com/2020/03/intelx86-root-of-trust-loss-of-trust.html