CVE-2018-18440 and CVE-2018-18439: U-Boot boundary checks

CVE-2018-18440: U-Boot insufficient boundary checks in filesystem image load

CVE-2018-18439: U-Boot insufficient boundary checks in network image boot

 

https://github.com/inversepath/usbarmory/blob/master/software/secure_boot/Security_Advisory-Ref_IPVR2018-0001.txt

Asset InterTech: Using U-boot as production test strategy — really?

https://blog.asset-intertech.com/test_data_out/2018/11/using-u-boot-as-production-test-strategy-really.html

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

U-Boot v2018.11-rc1 released

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.

https://lists.denx.de/pipermail/u-boot/2018-October/342659.html

CVE-2018-3968: Cisco using outdated U-boot in Cujo

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

https://lists.denx.de/pipermail/u-boot/2018-August/336973.html

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3968

——– Forwarded Message ——–
Subject: [U-Boot] Talos Security Advisory (TALOS-2018-0633/CVE-2018-3968 )
Date: Thu, 2 Aug 2018 18:52:03 +0000

Hello,

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.

U-Boot v2018.07 released …with Spectre work-arounds

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

More info:
https://lists.denx.de/pipermail/u-boot/2018-July/334014.html
http://git.denx.de/?p=u-boot.git
ftp://ftp.denx.de/pub/u-boot/
https://www.denx.de/wiki/U-Boot/

PS: Most recent set of U-Boot release stats:

https://www.denx.de/wiki/U-Boot/UbootStat_2018_07

CVE-2018-1000205: U-Boot, Verified Boot input validation

Re: https://firmwaresecurity.com/2018/06/26/cve-2018-1000205-u-boot/

and https://firmwaresecurity.com/2018/06/07/teddy-reed-on-u-boots-verified-boot/

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.

https://nvd.nist.gov/vuln/detail/CVE-2018-1000205

https://lists.denx.de/pipermail/u-boot/2018-June/330454.html

https://lists.denx.de/pipermail/u-boot/2018-June/330898.html

bootloader_instrumentation_suite: [U-Boot] Bootloader research tools (very much a work in progress)

https://github.com/bx/bootloader_instrumentation_suite

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.

REcon U-Boot talk, slides uploaded [temporarily]

http://cs.dartmouth.edu/~bx/recon.pdf

Teddy Reed on U-Boot’s Verified Boot

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 [1], [2], [3]. 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.

[1] https://lists.denx.de/pipermail/u-boot/2018-June/330454.html
[2] https://lists.denx.de/pipermail/u-boot/2018-June/330487.html
[3] https://lists.denx.de/pipermail/u-boot/2018-June/330599.html

https://lists.denx.de/pipermail/u-boot/2018-June/330898.html

Android bootloader flow documentation published

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.

https://lists.denx.de/pipermail/u-boot/2018-May/329886.html

https://source.android.com/devices/bootloader/

U-Boot gets Android Verified Boot (AVB) 2.0

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 [1] AVB 2.0 README and doc/README.avb2, which is a part of this patchset.[…]

https://lists.denx.de/pipermail/u-boot/2018-April/326562.html

 

Verified Boot – Introduction to U-Boot’s Secure Boot

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

https://www.pacificsimplicity.ca/blog/verified-boot-%E2%80%93-introduction-u-boot%E2%80%99s-secure-boot

 

Emulating Exynos 4210 BootROM in QEMU

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

https://www.fredericb.info/2018/03/emulating-exynos-4210-bootrom-in-qemu.html#emulating-exynos-4210-bootrom-in-qemu
https://github.com/frederic/qemu-exynos-bootrom

Exynos 4 Dual 45nm

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
https://www.fredericb.info/2016/10/amlogic-s905-soc-bypassing-not-so.html#amlogic-s905-soc-bypassing-not-so

Embedded Linux Japan Technical Jamboree 63 slides/videos uploaded

Status of Embedded Linux, Tim Bird
Review of ELC Europe 2017, Tim Bird
mplementing state-of-the-art U-Boot port, 2017 edition, by Marek Vasut
Linux カーネルのメモリ管理の闇をめぐる戦い(協力者募集中, Tetsuo Handa (NTT Data)
Request for your suggestions: How to Protect Data in eMMC on Embedded Devices, Gou Nakatsuka (Daikin)
Fuego Status and Roadmap, Tim Bird
Multicast Video-Streaming on Embedded Linux environment, Daichi Fukui (TOSHIBA)
From 1 to many Implementing SMP on OpenRISC, Stafford Horne
Core Partitioning Technique on Multicore Linux systems, Kouta Okamoto (TOSHIBA)
Debian + YoctoProject Based Projects: Collaboration Status, Kazuhiro Hayashi (TOSHIBA)

https://elinux.org/Japan_Technical_Jamboree_63#Agenda

See-also: Septemer 2017 Jamboree 62:

Status of Embedded Linux, Tim Bird
EdgeX Foundry: Introduction and demonstration of end to end IoT system, Victor Duan, Linaro
Lighting Talk: Integration between GitLab and Fuego, Tomohito Esaki, IGEL Co., Ltd.
DebConf17 Report, Kazuhiro Hayashi, TOSHIBA
Lightning Talk : About the LTS now, Shinsuke kato, Panasonic Corporation
Kernel Recipes 2015 – Linux Stable Release process, Greg KH
Lightning Talk: IPv6 Ready Logo Test for LTSI 4.9 and introduction about CVE-2016-5863 and CVE-2017-11164, Fan Xin, Fujitsu Computer Technologies Limited

https://elinux.org/Japan_Technical_Jamboree_62#Agenda

Environment variable whitelisting patch for U-Boot

Quentin Schulz of Free Electrons submitted a patch to U-Boot, adding whitelisting of variables, based on a patch by Maxim Ripard of Free Electrons.

[PATCH 00/11] Introduce variables whitelisting in environment

This patch series is based on a patch series from Maxime. This is an RFC. It’s been only tested in a specific use case on a custom i.MX6 board. It’s known to break compilation on a few boards. I have a use case where we want some variables from a first environment to be overriden by variables from a second environment. For example, we want to load variables from the default env (ENV_IS_NOWHERE) and then load only a handful of other variables from, e.g., NAND. In our use case, we basically can be sure that the default env in the U-Boot binary is secure but we want only a few variables to be modified, thus keeping control over the overall behaviour of U-Boot in secure mode. It works in that way:
– from highest to lowest priority, the first environment that can be loaded (that has successfully init and whose load function has returned no errors) will be the main environment,
– then, all the following environment that could be successfully loaded (same conditions as the main environment) are secondary environment. The env variables that are defined both in CONFIG_ENV_VAR_WHITELIST_LIST and in the secondary environments override the ones in the main environment,
– for saving, we save the whole environment to all environments available, be they main or secondary (it does not matter to save the whole environment on secondary environments as only the whitelisted variables will be overriden in the loading process
[…]

[1] https://patchwork.ozlabs.org/cover/842057/

For more info, see full email/patch on:
https://lists.denx.de/listinfo/u-boot