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:

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.[…]

Zynamics: BinDiff 6 released

Available for Mac, Windows, and Debian. With Ghidra support (BinExport).

SkySafe: Defeating a Laptop's BIOS Password

We found a laptop laying around the office that had BIOS password enabled. On top of that, the laptop had secure boot turned on. We wanted to run an OS that was not signed with Microsoft’s keys, so we really needed a way to get into the setup utility.[…]

SCAP CWE: new Hardware view, organizes weaknesses around concepts that are frequently used or encountered in hardware design

Mitre has updated SCAP’s CWE to include Hardware (but not Firmware). SCAP is the main method to keep the industry informed of security issues. However, it has been mostly focused on userspace app and OS issues, and pretty much ignoring hardware and firmware. Similar to how ‘ring 0’ means so much, and security researchers created multiple ‘negative rings’ to help clarify things, mostly for hw/fw.

Outside of userspace apps, SCAP is not useful IMO because it doesn’t let you find HW/FW issues. An ARM TrustZone issue will be hidden in an Apple iPhone app CVE, an Intel UEFI bootloader issue will be hidden in a Windows OS CVE, etc. You can’t use SCAP’s metadata to explicitly search for HW/FW issues, you have to hope for the best with a full-text search, and hope that the iPhone CVE also mentioned TrustZone, etc.

Now, security tools need to issue these HW CWEs, too.

It looks like there might be some hope for SCAP after all. They just updated one of their XML languages to support Hardware (not Firmware). So when the rest of SCAP is updated, and vendor tools support it, then future issues can be more-easily identified, Existing and prior issues will likely be not back-ported to use this new metadata, so ‘full-text search’ will likely be needed to search NIST NVD for historical HW issues …and will continue to be needed for FW issues, since CWE is only updated for HW, not FW…

Unclear if IETF SACM — which is related to SCAP — adopts this view. PowerShell script to create a Bootable USB drive for UEFI devices to install Windows

[…]Automatically mount the .iso
Automatically inject Drivers […]
Clear the USB drive of all partitions/files/data
Partition the USB drive with GPT and FAT32
Copy all contents of the ISO to the USB drive
Split the install.wim if it’s larger than 4GB
Optionally create another USB drive (loops)
Clean up temporary files and dismount the ISO

Microsoft: where is your latest dbxupdate.bin? UEFI Forum: why aren't you hosting the file as well?

With recent Kaspersky key issue, I did a quick check to see what the latest UEFI DBX (Secure Boot revocation file) was. Appears to be last-updated in 2016!

Where can I visit the Microsoft web site (or other online resources) to determine the latest version of the Microsoft DBX file? Currently I have to look in Peter’s dbxtool sources for an URL, hoping that the Red Hat dbxtool has the latest Microsoft DBX blob:

And that Microsoft web page is dated 3016. I would expect there to be some place on similar to the UEFI Forum’s UEFI Recovation File page:

Both the and DBX files are still dated 2016. I would expect to see a page that lists the recent Kaspersky issue alongside a 2020 date.

Or better yet, host the Microsoft DBX file alongside the DBX file, hosted on Why does the UEFI CA host partial DBX files on the UEFI Forum site and partially on their private company web site? It doesn’t make sense to have the DBX split into two files hosted on two different sites, one pertty much hidden and not discoverable.

I wish the UEFI CA would document this process. From current UEFI documentation, it would appear that the ONLY DBX file is hosted at, no mention about blob.

I presume Microsoft OS tools have clean integration with both web site’s DBX files, and get the latest ones from when they update it. The only other OS I’m aware of which has a DBX-checking tool is Red Hat, with their dbxtool. I’m not aware of any other Linux distro that uses dbxtool.

MacOS has their own Secure Boot, and haven’t integrated their keys with the UEFI CA (Microsoft), but I don’t know how the Apple UEFI implementation handles DBX file(s) today, …or will in the supposed future date when they start integrating Secure Boot keys with rest of UEFI ecosystem.

Pretty messed up.

MCUBoot and related code

An interesting history — to me, at least — of bootloaders, in above tweets from Colin.

J6-UEFI-Headers: Custom C++ headers for interfacing with UEFI

As mentioned in a few other blog posts, UEFI Forum seems to focus only on their Tianocore-based projects, and don’t consider UEFI apps built outside the Tianocore environment (in C, C++, or Rust). I wish they’d create a project that provides bindings for other languages, to be usable outside the Tianocore Build environment, where most developers operate. Here’s another source of external (to UEFI Forum) headers:

[…]This is a set of headers for interacting with UEFI as a C++ EFI application. I found the EDK2 headers seemed to be missing some definitions (or perhaps I just hadn’t found the right headers to include), and the GNU-EFI ones to be specific to using GNU-EFI and tended to break when using clang to natively build an EFI application.[…]

more on Kaspersky UEFI Secure Boot issue…


Kaspersky has a response:

Which has some feedback from at least 2 security researchers:

There is more info from other media source:

Microsoft Pulls Buggy UEFI Security Update | Decipher

The mess behind Microsoft’s yanked UEFI patch KB 4524244 | Computerworld

I wish the UEFI Certificate Authority would kick in right about now with a technical response.

Swift-Apple-EFI-Patcher: Apple EFI Patcher written in Swift with Flashrom Integration

Apple EFI Patcher written in Swift with Flashrom integration. This application was developed out of a need for a simple user-friendly and native macOS based approach to working with Apple EFI roms. The result is an all-in-one application capable of utilizing affordable SPI / eeprom chip reading hardware for reading/dumping from, patching and writing to EFI Rom chips. This application integrates flashrom support in order to communicate with hardware, thus incorporating a lot of the methodologies and current hardware already utilized by technicians.[…]