Multiple Cisco UCS-Based Products UEFI Secure Boot Bypass Vulnerability


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.

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20200219-ucs-boot-bypass

auto-UEFI-entry: An interactive tool to auto-generate UEFI-entries

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.

https://github.com/de-arl/auto-UEFI-entry

rpi4-uefi.dev: SBBR-compliant (UEFI+ACPI) AArch64 firmware for the Raspberry Pi 4

Andrei has a new web site to help with RPI4 UEFI use:

https://rpi4-uefi.dev/

There is also some info for RPI3 users.

Tianocore to get RISC-V port

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.

https://bugzilla.tianocore.org/show_bug.cgi?id=2532

https://bugzilla.tianocore.org/show_bug.cgi?id=2533

https://github.com/riscv/riscv-uefi-edk2-docs

https://github.com/tianocore/edk2-staging/tree/RISC-V

NetBSD 9.0 released, with AArch64 UEFI support

Armv7 gets UEFI bootloader:

https://www.netbsd.org/releases/formal-9/NetBSD-9.0.html

See-also:

https://wiki.netbsd.org/Installation_on_UEFI_systems/

Kaspersky bootloader UEFI Secure Boot vulnerability

There is something going on w/r/t UEFI Secure Boot keys and Kaspersky.

I wish I could clarify the issue better, but for now it is just a bunch of tweets…

MNT Reform: Open Source DIY Laptop for Hacking, Customization, and Privacy

There’s an open source hardware laptop that is getting started on CrowdSupply:

Free & Open Source: all firmware, hardware, and software, binary-blob-free Linux desktop with open Etnaviv GPU drivers

https://www.crowdsupply.com/mnt/reform

https://source.mntmn.com/MNT/reform

See-also:
https://mntmn.com/reform/

Azeria Labs: Understanding TEEs and Arm TrustZone

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 Hughes: Hunting UEFI Implants

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.[…]

Lanner: Security-enhanced BIOS

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.

http://www.lannerinc.com/products/firmware-and-software/securityenhanced-bios#

The page has some download links, last updated in 2018, The doc links work, but the link to the BIOS download doesn’t work (at least for me).

Intel releases 6 security advisories

Intel has released 6 new security advisories:

RWC3 Advisory, INTEL-SA-00341
MPSS Advisory, INTEL-SA-00340
RWC2 Advisory, INTEL-SA-00339
SGX SDK Advisory, INTEL-SA-00336
CSME
Advisory, INTEL-SA-00307
Renesas Electronics USB 3.0 Driver Advisory, INTEL-SA-00273

https://www.intel.com/content/www/us/en/security-center/default.html

Rust-based UEFI test framework

From Bret Barkelew of Microsoft:

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…

https://edk2.groups.io/g/devel/message/53252

https://github.com/corthon/edk2-staging/tree/rust_and_tests

IETF: Remote Attestation Procedures Architecture

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).

https://tools.ietf.org/html/draft-ietf-rats-architecture-01

Discussion on RATS: https://mailarchive.ietf.org/arch/browse/rats/

BGRTInjector: Customize boot logo without modifying UEFI

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.

https://github.com/Jamesits/BGRTInjector

DevOps for Embedded

Paul’s first post in a long while – I stumbled on this series of articles which are excellent if you happen to be developing and deploying embedded firmware.

Part 1: https://www.stupid-projects.com/devops-for-embedded-part-1/

Part 2: https://www.stupid-projects.com/devops-for-embedded-part-2/

Part 3: https://www.stupid-projects.com/devops-for-embedded-part-3/

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.!

hwsec_lecture_notes: Lecture notes for the Hardware and Embedded Systems Security lecture

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.

https://github.com/david-oswald/hwsec_lecture_notes