DRIPSEnabler: This UEFI program enables Intel PEP (Power Engine Plug-in) and adds support for DRIPS if your firmware didn’t support it natively. DRIPS allows more devices being shut down during S0ix, thus saving more energy.[…]
Hmm, today I learned about Lanner Electronics, in Taiwan, who ships a “secure BIOS” product.
Lanner witnesses the growing awareness of potential security risk for the pre-OS level and offers advnaced security features integrated within our exclusive BIOS designs. Lanner’s BIOS firmware offerring including market-proven technologies such as Secure Boot and Intel Boot Guard technology deliver solid commitments for the shield protection against malware, uncertified sequences and other named cyber threats. For specific applications, Lanner’s security-enhanced BIOS can be customized with the services covering DMI data pool, customer logo and password protection.
What’s better than UnitTests almost being ready for deployment in TianoCore? How about using those UnitTests to validate a native Rust port of one of our VarCheck libs? Building upon Jiewen’s work (among others) I’ve finally managed to prototype a port of the UefiVariablePolicyLib to Rust, and have shown that it can build as part of our normal CI process and run the same UnitTests that are used for the C version…
In network protocol exchanges, it is often the case that one entity (a Relying Party) requires evidence about a remote peer to assess the peer’s trustworthiness, and a way to appraise such evidence. The evidence is typically a set of claims about its software and hardware platform. This document describes an architecture for such remote attestation procedures (RATS).
With BGRT hacking, users can update the OEM boot logo graphic with their own. Apparently this is very popular, there’re a few BGRT posts on this blog that’re consistantly highly-viewed. Here’s a new BGRT tool:
Changes the boot screen image on a UEFI computer. This is a remake of Ben Wang’s windows_custom_loader.efi, the source code of which is long lost. Several incompatiblities with non-Apple UEFI implementations are addressed, and you can now replace the logo without recompiling the whole program.
Security: Loading untrusted image into memory is dangerous. BGRTInjector only reads the image file from the volume (partition) it lives in, and ESP partition is usually protected under end-user accessible operating systems, so we can assume only a system administrator or a evil maid can load an evil image. Additionally BGRTInjector does some basic sanity checks on the image file, but it is still prone to specially crafted evil images. If you are not signing your own Secure Boot keys, using BGRTInjector means Secure Boot will be unavailable. In Windows loader mode, BGRTInjector does not verify the authenticity of the target bootloader.
Also if your job still has some hardware for which you’re somehow responsible (ie: you’re not 100% on someone else’s cloud service!) these are worth a read. While your employer might just be a consumer of the end product – shipped versions of firmware on hardware that you buy / already own, it is worth understanding what is involved in making that firmware and shipping updates.!
These are my notes for an introductory lecture covering efficient implementation as well as implementation attacks (side channels, faults). It is by far not completely covering this much more complex field, but should give a decent overview and pointers for further reading.
Acknowledgements: Intel would like to thank the following individuals for finding, reporting and coordinating these vulnerabilities to us. Intel thanks TU Graz and KU Leuven for disclosure of CVE-2020-0549. Graz University of Technology: Moritz Lipp, Michael Schwarz, Daniel Gruss. KU Leuven: Jo Van Bulck. Intel thanks VU Amsterdam, for disclosure of CVE-2020-0548 and CVE-2020-0549. VUSec group at VU Amsterdam: Stephan van Schaik, Alyssa Milburn, Sebastian Österlund, Pietro Frigo, Kaveh Razavi, Herbert Bos, Cristiano Giuffrida. Researchers from TU Graz and Ku Leuven provided Intel with a Proof of Concept (POC) in May 2019 and researchers from VU Amsterdam provided Proof of Concept (POC) in October 2019. Intel subsequently confirmed each submission demonstrates CVE-2020-0549 individually.
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.