Excerpt from comments in part1 of patch:
When booting a FIT, if ‘bootm’ is used without a specified configuration, U-Boot will use the default one provided in the FIT. But it does not actually check that the signature is for that configuration. This means that it is possible to duplicate a configuration conf-1 to produce conf-2 (with all the signatures intact), set the default configuration to conf-2 and then boot the image. U-Boot will verify conf-2 (in fact since hashed-nodes specifies the conf-1 nodes it will effectively verify conf-1). Then it will happily boot conf-2 even though it might have a different kernel. This series corrects this problem and adds a test to verify it. It also updates fit_check_sign to allow the configuration to be specified. This vulnerability was found by Dmitry Janushkevich and Andrea Barisani of F-Secure, who also wrote the vboot_forge script included here. This is CVE-2020-10648. […]
No useful info yet:
Tom Rini of Konsulko announced the latest release of U-Boot, including a bit of info about the two recent CVEs:
[…]I’m going to mention here as well that both CVE-2018-18439 and CVE-2018-18440 exist and are issues. As a community we’re still working on more robust fixes to them, but I want to thank Simon Goldschmidt for taking the lead on coming up with code changes for them. In the immediate term (and for older releases) note that the filesystem-based attack can be mitigated by passing a maximum size to the load command.[…]
Wolfgang Denk of DENX has some stats about the release at:
Tools and techniques for traversing treacherous code bases
– or- How I managed to develop understanding of U-Boot
Click to access blackhoodie-slides-bx.pdf
Jordan Rhee of Microsoft has created a new project. All the documentation was used for the Title.
Now I’m wondering what Project Cyres is.
CVE-2018-18440: U-Boot insufficient boundary checks in filesystem image load
CVE-2018-18439: U-Boot insufficient boundary checks in network image boot
[…]Here is where I see a dilemma with using U-Boot for test. First I have to build U-Boot, and second have enough of the system operational, DDR (DDR controller/PHY) and SD flash interface etc. before testing can begin. Testing often involves non-operational system or minimally functionally operational hardware. The use of U-Boot expects a significant portion of the target hardware operational.
Second, assuming that you were successful in building U-Boot you now need to load it on the flash of the UUT. Be sure to follow the below warning. If U-Boot is already installed and running on your board, you can use these instructions to download another U-Boot image to replace the current one.
Warning: Before you can install the new image, you must erase the current one. If anything goes wrong your board will be dead. It is strongly recommended that you have a backup of the old, working U-Boot image or you know how to install an image on a virgin system.
Next U-Boot has limited testing capabilities.[…]
The RC of the November release of U-Boot is out. Usually, you basically haev to follow the U-Boot mailing list to track changes, but this announcement was more verbose than normal:
List of changes between -rc1 and -rc2:
– The SPI-NAND changes have fully been integrated now.
– ARM Versatile Express updates
– QEMU support in RiscV
– Rockchip updates
– fixes to rkimage for SPL boot via USB
– fixes to make_fit_atf.py, incl. entry-point calculation and python3 compatibility
– OP-TEE support for ARMv7-based SoCs
– fixes to RGMII/GMII selection on the RK3328
– ARC updates
– CPU and board info prints
– Synopsys IoT development kit support
– Take care of global uninitialized variables.
– Add support for SD-card detection on all ARC boards
– R-Mobile, SoCFPGA updates
– Sandbox SPL/TPL support
– Various DM, Test updates.
– Various general ARM, Meson, TI K2/K3 updates
– OP-TEE AVB support
We’re looking at release on November 12th, 2018.
Let’s hope Cisco Talos will let Mitre/NVD about the details soon. No info on the Talos or Cisco security sites, nor even *Twitter*!, AFAICT. 🙂
——– Forwarded Message ——–
Subject: [U-Boot] Talos Security Advisory (TALOS-2018-0633/CVE-2018-3968 )
Date: Thu, 2 Aug 2018 18:52:03 +0000
Cisco Talos team discovered a security issue impacting Cujo product using an outdated version of U-boot. We’ve assigned a CVE for this issue (CVE-2018-3968) and have attached a copy of the security advisory provided to Cujo.
Tom Rini announced the latest release of U-Boot, on the u-boot mailing list:
[…]On the ARM side of things, we have the framework in, and in some cases, it is now enabled, what portion of the “Spectre” work-arounds. Since dealing with the issues entirely is a system-level problem and not just “whack some bits once and you’re good” I want to stress that to deal with the issue entirely you’re going to need more than just these changes enabled.[…]
[IMO, the U-Boot project has terse release announcements; to really understand what is new in U-Boot, you have to diff the sources and track all the current patches and issues on the mailing list, and the list is high-traffic and one of the main posters does not have an email client that properly supports threading…]
PS: Most recent set of U-Boot release stats:
There is now a description for the CVE. Ah, this makes sense, the Verified Boot issues that Teddy Reed brought up earlier:
U-Boot contains a CWE-20: Improper Input Validation vulnerability in Verified boot signature validation that can result in Bypass verified boot. This attack appear to be exploitable via Specially crafted FIT image and special device memory functionality.
“This vulnerability has been received by the NVD and has not been analyzed.”
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.
Alex Deymo notes that the Android project has more documentation on their boot process, and posted about it on the U-Boot mailing list:
“Just an FYI, earlier this month the team spent some time polishing and publishing in source.android.com documentation about the flows the bootloader goes through in Android, specially true for stock Android like in Pixels phones or other devices based of recent AOSP versions. This documentation includes the interaction between userspace and the bootloader such as the properties userspace expects when booting A/B devices, the whole A/B flow, the bootloader message in the misc partition (BCB), how they interact with the “recovery mode” in Android and much more.
Igor Opaniuk of Linaro posted a patch to the U-Boot list, adding Android Verified Boot 2.0 support:
This series of patches introduces support of Android Verified B oot 2.0,which provides integrity checking of Android partitions on MMC. It integrates libavb/libavb_ab into the U-boot, provides implementation of AvbOps, subset of `avb` commands to run verification chain (and for debugging purposes), and it enables AVB2.0 verification on AM57xx HS SoC by default. Currently, there is still no support for verification of A/B boot slots and no rollback protection (for storing rollback indexes there are plans to use eMMC RPMB). Libavb/libavb_ab will be deviated from AOSP upstream in the future, that’s why minimal amount of changes were introduced into the lib sources, so checkpatch may fail. For additional details check  AVB 2.0 README and doc/README.avb2, which is a part of this patchset.[…]
Noticed a new document on Slideshare on U-Boot and AVB:
Verified Boot – Introduction to U-Boot’s Secure Boot
Submitted by admin on Sun, 09/24/2017 – 13:37
First things first, Uboot for the uninitiatited is an open source bootloader that is commonly used on Linux ARM, and MIPS systems, but has roots in the PowerPC (PPC) days. It supports a number of computer architectures and is secretly hiding away in many devices you or I use everyday (e.g., home routers).[…]
[…]This project allows to debug BootROM dynamically with GDB. It has been helpful for analyzing secure boot mechanism that loads and authenticates the next stage from flash memory.[…]
Nicely-written. Includes coverage of U-Boot and U-Boot Secure Boot.
PS: I just learned about this blog. Catching up, there are some interesting older posts, eg:
Amlogic S905 SoC: bypassing the (not so) Secure Boot to dump the BootROM