Advisory ID: cisco-sa-20200219-ucs-boot-bypass First Published: 2020 February 19 16:00 GMT Workarounds: No workarounds available Cisco Bug IDs: CSCvn09490 CSCvq27796 CSCvq27803
A vulnerability in the firmware of the Cisco UCS C-Series Rack Servers could allow an authenticated, physical attacker to bypass Unified Extensible Firmware Interface (UEFI) Secure Boot validation checks and load a compromised software image on an affected device. The vulnerability is due to improper validation of the server firmware upgrade images. An attacker could exploit this vulnerability by installing a server firmware version that would allow the attacker to disable UEFI Secure Boot. A successful exploit could allow the attacker to bypass the signature validation checks that are done by UEFI Secure Boot technology and load a compromised software image on the affected device. A compromised software image is any software image that has not been digitally signed by Cisco. […]There are no workarounds that address this vulnerability. Cisco has released firmware updates that address this vulnerability. […]UEFI Secure Boot is enabled only in a small subset of Cisco UCS-based appliances. For all the other appliances, the feature is not used, so the vulnerability does not apply.
See security considerations in readme before using:
Auto-UEFI-entry — a bash script called “aufii” — is an interactive tool to auto-generate UEFI-entries. […] aufii works like this: aufii autodetects boot, root and swap partitions with blkid, asks you wether you need intel-ucode and which kernel you use and AUTOMATICALLY CREATES THE NECESSARY COMMANDS FOR YOUR UEFI-ENTRIES with efibootmgr. You can check which devices will be used and wether the auto-composed commands are correct. aufii will create a small executable and if thou wilst – execute it.[…] But carefully check the created commands, as wrong UEFI-entries will render a system unbootable. So you better have a live-system at hand when trying the tool late at night just for fun. Simply run aufii.
UEFI’s Tianocore implementation has built-in support for Intel/AMD and ARM. The RISCV-V port has been in a branch. Now it appears RISC-V is about to become part of the main branch, with 2 new packages, RiscVPkg and RiscVVirtPkg:
RISC-V is a new ISA which was designed to support computer architecture research and education. But now it becomes a standard open architecture for industry implementations. RISC-V edk2 project is to create a new processor binding in UEFI spec and to have RISC-V edk2 implementation. The goal is to have RISC-V edk2 port as the firmware reference for RISC-V platforms. Also, this proves the UEFI spec and edk2 implementation are flexible and well deisgned for adopting any processor architecture.The following modules are related to edk2 RISC-V port:
RiscVPkg – RISC-V processor package. This package provides RISC-V processor related protocols/libraries accroding to UEFI specification and edk2 implementations.
RiscVVirtPkg – RISC-V QEMU port. This is the RISC-V platform which is based on QEMU implementation. We use PC/At bus architecture as RISC-V platform bus spec. The image built from this package can be launched by QEMU RISC-V port.
This post is the first part of a larger series and aims to ease the process of getting started with TrustZone security research. If you ever wondered how Trusted Execution Environments on modern Android phones work and want to learn about their attack surface, you will find enough information in this series to get you started. In this introduction post, you will learn what the TrustZone technology is and what Trusted Execution Environments (TEE) are for. You can use this post as a reference for TrustZone and TEE concepts you don’t understand or remember when reading the follow-up posts.[…]
Richard is the main person behind LVFS, so he’s aware of the state-of-the-industry, is suggesting that vendors do more to document their firmware security, to help consumers with their threat models and purchases. These security levels should probably be done in sync with CVE/OVAL updates, so the same metadata can be used elsewhere in the security ecosystem.
SCAP? Consumer Reports? Tom’s Hardware? Other PC reviewers: you’re not helping.
[…]What I propose we do is assign some core protections some weight, and then verify and document how each vendor is configuring each model. For instance, I might say that for my dads laptop any hardware “SEC1” and above is fine as he’s only using it for Facebook or YouTube and it needs to be inexpensive. For my personal laptop I would be happy to restrict my choice of models to anything SEC3 and above. If you’re working as a journalist under some corrupt government, or am a security researcher, only SEC4 and above would be suitable. The reality is that SEC4 is going to be several hundred dollars more expensive than some cheap imported no-name hardware that doesn’t even conform to SEC1.[…]
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.