Load Value Injection (LVI): a “transient-execution attack” — it even has a movie trailer:
Link in below Tweet:
Moritz Lipp, Arthur Perais, Vedad Hadžić, Clémentine Maurice, Michael Schwarz, Daniel Gruss
Azeria Labs has released the 2nd installment of their TEE training:
This Tianocore bug is an interesting way to brick some systems:
[…] An attacker could do the following steps:
- Gain root access (can be due to revenge, or privilege escalation)
- Change the MemoryTypeInformationVar [..]
- Reboot the system (warm reboot)
- System bricked […]
In below Tweet, Huawei has released a video to dispel fears of ‘backdoors’:
Xeno has just added about a dozen new entries to this list. See above tweet for recent entries.
[…]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.[…]
Available for Mac, Windows, and Debian. With Ghidra support (BinExport).
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.[…]
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.
I think this is a new web page.
[…]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[…]
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 microsoft.com similar to the UEFI Forum’s UEFI Recovation File page:
Both the uefi.org and microsoft.com 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 UEFI.org DBX file, hosted on UEFI.org. 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 UEFI.org, no mention about Microsoft.com blob.
I presume Microsoft OS tools have clean integration with both web site’s DBX files, and get the latest ones from Microsoft.com 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.
An interesting history — to me, at least — of bootloaders, in above tweets from Colin.
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.[…]
Exciting, another frontend to GDB:
Kaspersky has a response:
Which has some feedback from at least 2 security researchers:
There is more info from other media source:
I wish the UEFI Certificate Authority would kick in right about now with a technical response.
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.[…]