CopperheadOS appears to becoming active again. There is — AFAICT — a new document on Verified Boot security.
The most severe vulnerability in this section could enable a local attacker to bypass user interaction requirements in order to gain access to additional permissions.
Vulnerability in the Solaris component of Oracle Sun Systems Products Suite (subcomponent: Verified Boot). The supported version that is affected is 11.3. Difficult to exploit vulnerability allows high privileged attacker with logon to the infrastructure where Solaris executes to compromise Solaris. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Solaris accessible data as well as unauthorized read access to a subset of Solaris accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Solaris.
Current Exploit Price (≈) 3.9 $5k-$25k
Teddy Reed, author of UEFI Firmware Parser, among other things, has some U-Boot Verified Boot issues:
Verified boot production uses question
Hi all, question, is anyone using the U-Boot verified-boot in production? I am using configuration verification for several OpenCompute/OpenBMC boards. After a deep-dive review I found some edge cases that in rare circumstances could lead to a signature check bypass. I think this is low-risk at best since the scenario requires special hardware behavior to exist. Our board were susceptible in the general sense, but we had implemented some additional sanity checks on the FIT structures that
prevented this. There are some proposed changes that attempt to mitigate this , , . Any one of these changes mitigates the bypass scenario. If you don’t mind reaching out to me I can share the exact situation/details.
[…]A recent branch title “firmware-eve-campfire” was discovered in the Chromium gerrit, accompanied by changes referencing “AltOS” and “go/vboot-windows.” That, combined that with the addition of placeholder strings for “Chrome OS” and “AltOS” being added to all languages, suggests that a future Chrome OS device, codenamed “Eve” will have the capability to boot more than one operating system. The commit was found by -nbsp- on Reddit. Obviously, with a name like “vboot-windows,” it is easy to jump to the conclusion that the feature is intended for Microsoft Windows, though little information about this is available. Most of the relevant code is hidden behind the private gerrit for Google employees, making it difficult to ascertain how this works and what it is intended for. According to a post at XDA-developers, it seems possible that this could be used for non-Windows OSes, such as Linux, or whatever Google Fuschia actually is.[…]
Noticed a new document on Slideshare on U-Boot and AVB:
I just noticed that the PCI compliance group lumps all of the Trusted/Measured/Verified/Secure boot technologies into one, and calls it Trusted Boot, which, AFAIK, is the name for Intel TXT-based Trusted Boot. I wish they were more precise. Then again, I guess I should be glad there is *SOME* firmware security in the PCI compliance docs, I wish there was more, system should check firmware-based code for malware, not just OS-based code.
Payment Card Industry (PCI)
Software-based PIN Entry on COTS Security Requirements
Version 1.0, January 2018
The PIN CVM Application must only support platforms that, at a minimum, provide the following features:
* An enforcing mandatory access control framework
* A “trusted boot” mechanism that validates the operating system’s authenticity
Trusted Boot: A cryptographic process where the bootloader verifies the integrity of all components (e.g., kernel objects) loaded during operating system start-up process, before loading. Also known as Verified Boot and Secure Boot (e.g., Google or Apple).
Dump/Verify Android Verified Boot Signature Hash
For researching Android Verified Boot issues
To exploit TZ image verification 🙂
python verify_signature.py boot.img
Issues: Might not work with AVB Version 2.0 or higher
The UEFI Forum likes to frame UEFI -vs- BIOS, and has a 3-5 Class heirarchy of those systems, including having to deal with UEFI systems that also provide BIOS via Compatibility Support Module (CSM), referring to BIOS as Legacy Mode. If you look at BIOS outside of the framing of the UEFI Forum, it is usually based security, and UEFI has some security where BIOS has none. But there’s another ‘class’: non-UEFI coreboot, optionally secured with Verified Boot, with a BIOS payload. UEFI Forum doesn’t include this in their Class heirarchy… AFAICT, the mainstream IBVs have given up on BIOS and migrated to UEFI. The only places where BIOS will probably remain are in Purism boxes, where they will use TPM+Heads to secure BIOS, or on Chrome boxes, where they will use coreboot Verified Boot to secure BIOS, or in SeaBIOS-based VMs. When Intel stops offering Intel’s implementation of BIOS, maybe this means that the remaining BIOS users will switch to the open source SeaBIOS project, which is great news. Getting rid of the complex class of dual UEFI/BIOS systems will be a joy. 🙂
This flew under our radar back at I/O, but it’s big news. On compatible devices, the new Verified Boot changes in Android 8.0 Oreo will prevent a device from booting should it be rolled back to an earlier firmware. The new feature is called Rollback Protection. So if your phone is flashed with older software, you (and your data) are protected from whatever potential security vulnerabilities may have been present in earlier versions. For 99% of users, the new Rollback Protection is great news. If a phone is lost or stolen, it further decreases the number of potential attacks which could be used to gain access, providing better safety for your data.[…]
This project takes Chrome’s Verified Boot (Vboot) process and examines its various security properties using formal logic. This verification is done with a focus on the firmware/hardware boundary. The Vboot process depends on the correct functionality of a Trusted Platform Module (TPM) and a SHA accelerator. Because these hardware accelerators are interacted with through Memory Mapped I/O (MMIO), it is difficult for normal formal methods to capture the interface between the MMIO registers and the workings of the Hardware modules. To explore this boundary I am using a Software TPM Library and passing it through to the QEMU Hardware Emulator. This allows me to use the normal MMIO registers of a TPM with the original Vboot Library.[…]
Signing boot images for Android Verified Boot (AVB)
Various Android devices support Android Verified Boot (AVB). A part of this is more commonly known as dm-verity, which verifies system (and vendor) partition integrity. AVB can however also verify boot images, and stock firmwares generally include signed boot images. Of course this does not mean that all signed boot images are using AVB, many OEMs have their own signature verification scheme. Note: AOSP is moving towards the use of avbtool (taken from Brillo), the following is the old way for signing boot images. Bootloaders might or might not accept unsigned boot images, and might or might not accept boot images signed with our own keys (rather than the OEM’s keys). This depends on the device, bootloader version, and bootloader unlock state. For example, with the bootloader unlocked, the Google Pixel (and XL) devices accepted unsigned boot images up to (but not including) the May 2017 release. From the May 2017 release onwards, the boot images must be signed if flashed (booted works without), but may be signed with your own key rather than the OEM’s. Note: The situation changes when you re-lock the bootloader. I have not tested this, but documentation implies that (one of) the keys used in the current boot image must be used for future flashes until it is unlocked again.[…]
Marc Kleine-Budde of Pengutronix gives a talk at the Embedded Linux Conference Europe (ELCE), on using Verified Boot.
coreboot version 4.4 has been released, which includes 850 commits by 90 authors added 59000 lines to the codebase since their last quarterly release. This release includes OpenPOWER support and experimental U-Boot payload support. It also has an Intel ME tool which is new (at least to me). There are many other changes, excerpting their announcement:
* Build system (30 commits) – Add postcar stage, ‘timeless’ builds, extend site-local, test toolchain by version string, update dependencies, catch ACPI errors, l add additional macros.
* Toolchain updates (40+ patches) – Update IASL to v20160318 , LLVM to v3.7.1, add GNU make, add nds32le GCC compiler
* Lint tools (30 patches) – Update existing lint utilities, add lint tests for executable bit, make sure site-local isn’t committed, add test to break all lint tests.
* Payloads (60 commits) – Fixes for libpayload, coreinfo and nvramcui, add new payloads, see below.
* Maintainers file – (8 patches) – continue adding maintainers for various areas.
* Documentation for adding Intel FSP-based platforms (20 commits)
* depthcharge: For ChromeOS verified boot
* iPXE: For network booting
* Memtest86+: Updated with fixes for correctly testing coreboot with payloads
* U-Boot (Experimental): Alternate payload for booting an OS
New vendorcode directories:
* 3rdparty/arm-trusted-firmware (329 commits)
* 3rdparty/vboot (28 commits)
* util/nvidia/cbootimage (13 commits)
* archive – Concatenates files into a single blob with an indexed header
* chromeos – Download and extract blobs from a ChromeOS image
* futility – vboot Firmware utility
* intelmetool – Shows information about the Intel ME on a platform.
* marvell/doimage_mv – No usage notes
* post – Simple utility to test post cards
Teddy Reed is proposing a change to U-Boot to support multiple levels of signing keys. Currently this is still at discussion phase, here’s Teddy’s initial post.
I’m looking to support “multiple levels” of keys within u-boot’s verified boot. I need something similar to UEFI’s key enrollment key (KEK) and db/dbx model such that I can support on-line signing of new kernels/rootfs/configurations. To make this work we need a KEK that is not online (kept in a safe), that can be used to sign expirations (revocations) of on-line signing keys in the case of compromise or private key reveals. I know Chrome’s Coreboot verified boot model supports this, wondering if there’s any staged / WIP for u-boot? Off the top of my head I’d imagine this requires extending the FIT to include sets of public keys and a blacklist of keys and expired or bad kernel/rootfs/etc hashes. Then either extending the boot code to inspect multiple FITs or extending mkimage to combine multiple sources to amalgamate a FIT containing the PK-signed set of keys + hashes and the on-line key-signed kernels/rootfs/configurations.
P.S. This may be strongly linked to the need for a TPM to prevent rollbacks. But as far as I can tell, the two features are distinct and a TPM is not completely required for a multi-level key approach to signing FITs.
Wow, there’s a lot of “Boot” buzzwords out there: U-Boot verified boot, Solaris Verified Boot, Chrome Verified Boot, Android Verified Boot (Class A and Class B), UEFI Secure Boot (sometimes called Windows Secure Boot), ARM TrustZone, UEFI Secure Boot, ARM TZ Secure Boot, Measured Boot (sometimes called TCG Measured Boot), Trusted Boot (Windows and Linux concepts) and most likely half a dozen others I don’t even know about… 🙂
UEFI Secure Boot aside, I’m still learning some of these other boot technologies, and how they overlap. I still have a LOT of questions about many of them. I think Verified Boot in Chrome and Android share the same Linux linux kernel technology, but have implemented things differently between Chrome and Android. UEFI’s Secure Boot doesn’t use a TPM, yet Microsoft requires OEMs to have a TPM. 😦 There’s the Trusted Boot that Windows has, and there’s also the tboot (Trusted Boot) loader that is Linux-centric. ARM’s TZ Secure Boot appears to be a different Secure Boot than the UEFI one. Solaris had their Verified Boot, but recently added UEFI support, so what is going to happen with UEFI Secure Boot, and will that mix with existing Solaris Verified Boot? Ditto on Android-IA, which only uses UEFI, will UEFI Secure Boot ever mix with Android Verified Boot?
None of these are full security solutions. For example, Intel has Boot Guard to help protect the system before UEFI Secure Boot’s protections kick in.
Below is a bit more information for each one. This is the first blog post on this topic, I’ll be doing further posts with more details about most of these in the future.
U-Boot verified boot
“U-Boot 2013.07 introduces a feature allowing for the verification of a kernel and other images. U-Boot’s new verified boot feature provides a mechanism for verifying images while still allowing them to be field-upgraded. It fits in seamlessly with the existing image loading infrastructure in U-Boot. U-Boot verified boot relies on two familiar technologies: cryptographic hashing (e.g. SHA-1) and public key cryptography (e.g. RSA). Using these technologies it is possible to distribute images and have them verified on a device. Specifically we can create a key, hash an image, sign that hash, and publish the public key. On the device we can obtain an image and verify it was signed by the private key. Images can be chained one after the other and signed in reverse order either using the same keys or sub-keys (keys derived from other keys). For example, U-Boot may load an image containing a new U-Boot, then boot that. That U-Boot in turn may load an image containing a kernel. Doing that would allow U-Boot itself to be updated with the firmware without risking having an unbootable device due to a bad update. In principle this chain can be any length, but there must be an initial trusted image (“root of trust”) that can start the process. This can be stored in read-only media during manufacture or perhaps protected by on-chip crypto using its own signing scheme. The “root of trust” U-Boot must include the initial public key, held in U-Boot’s device tree (often called the flattened device tree or FDT). A more sophisticated scheme would allow the public keys to be provided by the user, perhaps by inserting an SD card containing the key. This could be implemented using a U-Boot script or with a more sophisticated user interface. A TPM can be used to hold rollback counters, to protect against rolling back to an older, compromised firmware. U-Boot also provides TPM support for trusted boot and remote attestation.”
Solaris Verified Boot
“Solaris Verified Boot is a solution for Oracle’s version of Solaris. Solaris Verified Boot refers to verification of object modules before execution using digital signatures. If enabled, Solaris Verified Boot checks the factory-signed signature in a kernel module before loading and executing the module. This is to detect accidental or malicious modification of a module. The action taken is configurable and, when enabled, will either print a warning message and continue loading and executing the module or will fail and not load and execute the module. Solaris Verified Boot checks kernel modules before execution and reports if the module is modified. Optionally on failures, the module is not loaded. For Solaris, Solaris Verified Boot will verify kernel modules before execution, beginning with the initial bootstrap SPARC ‘bootblk’ sectors and initial ‘unix’ module. Both of these are verified by SPARC OpenBoot (because Solaris is not running yet). The Solaris kernel loader (krtld) then takes over and verifies the main (generic) “genunix” module and all subsequent modules loaded by the Solaris kernel. The policy to use on failures is configurable with three policy settings: none, warning, and enforce. The default policy is none (that is, Verified Boot is disabled); None is the default behavior — no verification before execution. Re: TPMs, Solaris Verified Boot has no impact on the TPM chip or TPM software (TrouSerS). However, the TPM still serves complementary functions such as providing a secure keystore or taking measurements of firmware executibles. Verified Boot settings are maintained by Oracle ILOM. Anyone with ILOM spsh shell access can modify these settings. Solaris Verified Boot is available with Solaris 11.2 for Sun SPARC T5/M5/M6 hardware platforms for host domains (with Sun Firmware FW 9.1.0 or better) and Fujitsu M10 systems (with Firmware XCP2250 firmware). Verified Boot is supported for the host domain in the Global Zone. Non-global, non-kernel zones do not have their own copy of the Solaris kernel and do not load kernel modules. Verified Boot is not supported initially for Solaris on X86, T4 or older SPARC platforms, LDoms guest domains, or Kernel Zones. We plan to support more hardware.”
Chrome Verified Boot
“Chrome Verified Boot is a solution for Google’s Chromium OS. The Chromium OS team is implementing a verified boot solution that strives to ensure that users feel secure when logging into a Chromium OS device. Verified boot starts with a read-only portion of firmware, which only executes the next chunk of boot code after verification. Verified boot strives to ensure that all executed code comes from the Chromium OS source tree, rather than from an attacker or corruption. Verified boot is focused on stopping the opportunistic attacker. While verified boot is not expected to detect every attack, the goal is to be a significant deterrent which will be improved upon iteratively. Verification during boot is performed on-the-fly to avoid delaying system start up. It uses stored cryptographic hashes and may be compatible with any trusted kernel. This feature is not expected to provide 100% detection of attacks. Instead, it is meant to raise the attack bar significantly and in a way that can be improved upon iteratively.”
Android Verified Boot
“Android Verified Boot is a solution for Google’s Android OS. Android’s Verified boot guarantees the integrity of the device software starting from a hardware root of trust up to the system partition. During boot, each stage verifies the integrity and authenticity of the next stage before executing it. This capability can be used to warn users of unexpected changes to the software when they acquire a used device, for example. It will also provide an additional signal of device integrity for remote attestation, and together with encryption and Trusted Execution Environment (TEE) root of trust binding, adds another layer of protection for user data against malicious system software. We define two implementation classes for verified boot depending on how fully the device implements this specification. Class A implements verified boot with full chain of trust up to verified partitions. This implementation must support the LOCKED device state, and GREEN and RED boot states. Class B implements Class A and additionally supports the UNLOCKED device state and the ORANGE boot state.”
UEFI Secure Boot
“UEFI Secure Boot, sometimes called Windows Secure Boot, is an optional security feature of UEFI that can be enabled by a PC OEM to enhance the security by helping to make sure that your PC boots using only software that is trusted by the PC manufacturer. When the PC starts, the firmware checks the signature of each piece of boot software, including firmware drivers (Option ROMs) and the operating system. If the signatures are good, the PC boots, and the firmware gives control to the operating system. Secure Boot does not require a TPM.”
“I think some refer to Measured Boot as TCG Measured Boot. Windows supports Measured Boot, Trusted Boot, and Secure Boot. Windows 8 introduces a new feature called Measured Boot, which measures each component, from firmware up through the boot start drivers, stores those measurements in the TPM on the machine, and then makes available a log that can be tested remotely to verify the boot state of the client. The Measured Boot feature provides AM software with a trusted (resistant to spoofing and tampering) log of all boot components that started before AM software. AM software can use the log to determine whether components that ran before it are trustworthy or if they are infected with malware. The AM software on the local machine can send the log to a remote sever for evaluation. The remote server may initiate remediation actions either by interacting with software on the client or through out-of-band mechanisms, as appropriate. Working with the TPM and non-Microsoft software, Measured Boot in Windows 8.1 allows a trusted server on the network to verify the integrity of the Windows startup process.”
UEFI Secure Boot aside, it appears that ARM TrustZone also uses Secure Boot as a non-UEFI-based concept:
“Windows supports Measured Boot, Trusted Boot, and Secure Boot. With Trusted Boot, Windows checks the integrity of every component of the startup process before loading it. Trusted Boot takes over where Secure Boot leaves off. The bootloader verifies the digital signature of the Windows 8.1 kernel before loading it. The Windows 8.1 kernel, in turn, verifies every other component of the Windows startup process, including the boot drivers, startup files, and ELAM. If a file has been modified, the bootloader detects the problem and refuses to load the corrupted component. Often, Windows 8.1 can automatically repair the corrupted component, restoring the integrity of Windows and allowing the PC to start normally.”
“Trusted Boot (boot) is ALSO the name of an open source, pre-kernel/VMM module for Linux, that uses Intel TXT to perform a measured and verified launch of an OS kernel/VMM. Intel TXT provides a hardware- based root of trust to ensure that a platform boots with a known good configuration of firmware, BIOS, virtual machine monitor, and operating system.”
Enterprises which are responsible for user/data security usually like these kinds of technologies. Citizens who like to control their own devices, including installing their preferred operating system, instead of using the pre-installed OEM OS, often find these security technologies a hindrance to their normal usage. OEMs — except Google, with the Developer Mode of their ChromeBook — ignore this latter, smaller consumer demographic, and focus strictly on the security-focused market, creating opportunities for “micro-OEMs” like Purism and Bunnie Studios.
As reported by multiple online news sources, Android is getting some UI changes related to Verified Boot. Quoting Android Police article:
“Google has just added an interesting page to the Nexus support site that lists new operating system safety warnings. According to the page, this is a boot verification system that checks the integrity of your device software during each startup. You probably haven’t seen this on any devices yet, but Android M is right around the corner.”
Stephan of the coreboot project is currently having a Twitter conversation with some others. It includes this post:
This makes me wonder, has anyone compared Chrome’s Verified Boot with UEFI’s Secure Boot. With and w/o TPM chip on Intel or TrustZone on ARM. It would be nice if some cyypto-savvy researchers could analyze the crypto used in both implementations and give a comparison, including how these solutions meet the NIST and NSA/CC criteria for securing BIOS.
In terms of code size, coreboot has a much smaller codebase than tianocore, even with the all the additional size that Chrome brings to it’s coreboot dialect. But both Secure Boot and Verified Boot are nearly the same in terms of PKI.
On a related not, I’ll do a future blog post looking into the various boot flavors: Trusted Boot, Secure Boot, Measured Boot, Verified Boot, etc.
I mainly work with UEFI technology, and don’t know much about coreboot, nor Chrome OS. I’m new to these tech, and learning them… 🙂
For a while, I thought coreboot was pretty inactive, but I now realize much of the coreboot activity has been taking place in Chrome OS. It appears that some of this work is now being upstreamed to the main coreboot.
From the coreboot blog:
“In the last months there was lots of activity in the coreboot repository due to upstreaming the work that was done in Chrome OS’ branch. We’re happy to announce that both code bases are again relatively close to each other. In the last 7 months, about 1500 commits that landed in coreboot originated in Chrome OS’ repository (of about 2600 total). Those came from 20 domains, which represent pretty much every part of the coreboot community: well known private and commercial coreboot contributors, but also BIOS and silicon developers as well as device manufacturers. Significant contributions that went into the tree recently were written with active support by Broadcom, Imagination Technologies, Intel, Marvell, Nvidia, Qualcomm, and RockChip.”
“In the future, Chrome OS will move over to a new branch point from upstream, and work on strategies to avoid diverging for two long years again. Instead, we’re looking for ways to keep the trees closer while also avoiding flooding the coreboot.org developer base with hundreds of patches. More on that as it is implemented.”
Some features that’ve been recently added include:
* new MIPS support
* improved ARM support, for SoCs by Broadcom, Marvell, Qualcomm, and RockChip
* an improved, safer method to declare the memory map on devices
* effort to get Chrome OS’ verified boot support
* update the flash image format to allow for safer incremental updates
This looks like great news for coreboot! I’ll have more blog entries about coreboot and Chrome OS in the near future.