Make-UEFIUSB.ps: PowerShell script to create a Bootable USB drive for UEFI devices to install Windows

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

https://github.com/MrShannon007/Make-UEFIUSB

Microsoft: where is your latest dbxupdate.bin? UEFI Forum: why aren't you hosting the file as well?

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:

https://uefi.org/revocationlistfile

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.

https://support.microsoft.com/en-us/kb/3179577

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.

Pretty messed up.

MCUBoot and related code

An interesting history — to me, at least — of bootloaders, in above tweets from Colin.

https://git.trustedfirmware.org/trusted-firmware-m.git/tree/bl2/ext/mcuboot/bootutil/src/loader.c

https://mcuboot.com/

J6-UEFI-Headers: Custom C++ headers for interfacing with UEFI

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:

https://github.com/justinian/j6-uefi-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.[…]

more on Kaspersky UEFI Secure Boot issue…

Re: https://firmwaresecurity.com/2020/02/16/kaspersky-bootloader-uefi-secure-boot-vulnerability/

Kaspersky has a response:

Which has some feedback from at least 2 security researchers:

There is more info from other media source:

Microsoft Pulls Buggy UEFI Security Update | Decipher

The mess behind Microsoft’s yanked UEFI patch KB 4524244 | Computerworld

I wish the UEFI Certificate Authority would kick in right about now with a technical response.

Swift-Apple-EFI-Patcher: Apple EFI Patcher written in Swift with Flashrom Integration

Apple EFI Patcher written in Swift with Flashrom integration. This application was developed out of a need for a simple user-friendly and native macOS based approach to working with Apple EFI roms. The result is an all-in-one application capable of utilizing affordable SPI / eeprom chip reading hardware for reading/dumping from, patching and writing to EFI Rom chips. This application integrates flashrom support in order to communicate with hardware, thus incorporating a lot of the methodologies and current hardware already utilized by technicians.[…]

https://github.com/sadponyguerillaboy/Swift-Apple-EFI-Patcher

See-also:
https://github.com/sadponyguerillaboy/Python-Apple-EFI-Patcher

patch

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