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.
In below Tweet, Huawei has released a video to dispel fears of ‘backdoors’:
Does the word “#backdoor” seem frightening? That’s because it’s often used incorrectly – sometimes to deliberately create fear. Watch to learn the truth about backdoors and other types of network access. #cybersecuritypic.twitter.com/NEUXbZbcqw
Компания Intel поблагодарила экспертов #PositiveTechnologies, обнаруживших уязвимость в подсистеме Intel CSME. Уязвимость позволяет скомпрометировать ключи шифрования платформы и перехватить конфиденциальную информацию. Подробнее на https://t.co/65RjFlw344https://t.co/g8dswQnUdc
[…]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.[…]
I'm not especially worried about the new CSME vulnerabilities from a security perspective – they require a level of access that would give an attacker other ways to achieve most of the same goals. But anyone relying on SGX *should* be worried.
— Matthew Garrett (@mjg59@nondeterministic.computer) (@mjg59) March 6, 2020
— Christian Blichmann 🇺🇦 @AdmVonSchneider@infosec (@AdmVonSchneider) March 1, 2020
https://t.co/UtSzEpvsPI, mostly: – Experimental support for Ghidra disassembler (see BinExport) – Improved porting of symbols and comments – Bug fixes – "View in call graph context" from IDA
— Christian Blichmann 🇺🇦 @AdmVonSchneider@infosec (@AdmVonSchneider) March 1, 2020
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.[…]
I recently ported @osxreverser excellent UEFI DXE emulator to Windows. Now you can build the emulator from within VS and then use it to trace through your favorite DXE-phase driver.https://t.co/hdCnRf4Kob Contributions are welcome 🙂 pic.twitter.com/3bGXTMFQgV
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…
[…]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.
But it gets better. Cypress has the PSoC64 series, which is basically the PSoC62 but with manufacture-provided firmware running on the M0 "Secure Core". But guess what the secure bootloader is based on – that's right, https://t.co/u7lVl7zEn7! pic.twitter.com/r1Nme7lGdX
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.[…]
Firmware Security 
You must be logged in to post a comment.