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 “
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.
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.[…]
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 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.
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.
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.[…]
[…]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.[…]
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,[…]
[…]Further, we demonstrate JackHammer, a novel and efficient Rowhammer from the FPGA to the host’s main memory. Our results indicate that a malicious FPGA can perform twice as fast as a typical Rowhammer attack from the CPU on the same system and causes around four times as many bit flips as the CPU attack. We demonstrate the efficacy of JackHammer from the FPGA through a realistic fault attack on the WolfSSL RSA signing implementation that reliably causes a fault after an average of fifty-eight RSA signatures, 25% faster than a CPU rowhammer attack. In some scenarios our JackHammer attack produces faulty signatures more than three times more often and almost three times faster than a conventional CPU rowhammer attack.