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. […]
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.[…]
[…]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.
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
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…]
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.
My instrumentation toolsuite (now named Fiddle) still lacks an up-to-date README, but now has example targets (uboot/arm + test.c for multiple archs (writes only traced in arm)). Requires radare2 + gdb w/ python2. Run https://t.co/g2fXynKIkQ to install. https://t.co/Ywx8sSQ7Kf
A friendly reminder that this is research code (i.e., a brittle pile of crap), so it will probably be a headache both to get it to work and to work with. I plan on quietly and slowly updating the tools and documentation when I can find spare the time to do so.
This test suite helps you keep track of different versions of u-boot/build tools, static analysis of that build’s binaries, and runtime trace results of running that binary on a given hardware configuration. For each u-boot/build configuration it keeps a database of information it statically gathered for each boot stage, boot stage images/ELF files, a prepared SD card image, and test results of runtime trace analyses. If it detects changes in the u-boot source or build tools it will create a new set of test result directories with a new sdcard image and static analysis results.
.@bxsays did a really awesome talk on her work on instrumenting uboot memory writes in order to express memory policies to harden bootloaders at @reconmtl and the slides (missing during the talk due to technical issues) are now available and pretty spectacular clarifying things. https://t.co/1ckEJvxhEL
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.[…]
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).[…]