U-boot_boot-up_headpic.png

 

Memory handling issues in U-Boot open-source bootloader for embedded devices make possible multiple exploitation techniques that lead to arbitrary code execution.

 

U-Boot, short for the Universal Boot Loader, is a first-stage and second-stage bootloader. It is responsible for the initial hardware configuration and loading the operating system (OS) kernel.

 

It has support for a variety of architectures, including ARM, MIPS, and PowerPC. Among the types of devices it can initiate are Chromebooks, routers, and Amazon Kindle.

 

To ensure that authentic code is running on the system, U-Boot features 'Verified Boot' - its own version of Secure Boot - which verifies the integrity of the images it loads.

It's a memory allocation protection issue

Andrea Barisani, Head of Hardware Security at F-Secure warns about an architectural issue in the bootloader that doesn't provide sufficient checks on the available memory. This lapse can be exploited to defeat the validation process, allowing an attacker to load and execute custom code on the system.

 

Barisani discloses two methods that leverage U-Boot's lack of memory allocation restrictions. The flaws received the identifiers CVE-2018-18440 and  CVE-2018-18439.

 

The researcher says that the commands U-Boot uses to load the OS kernel do not protect against loading a boot image sufficiently large to overwrite a device's addressable memory, including the bootloader's memory segments.

 

"The memory overwrite can directly lead to arbitrary code execution, fully controlled by the contents of the loaded image," Barisani adds.

Bypassing file integrity checks

This problem is not solved through the verified boot feature because it kicks in after the process of overwriting the memory.

 

Demonstrating the issue was possible by writing a 129MB file on a system equipped with 128MB of RAM, taking over the memory addresses intended for U-Boot's data segments.

 

A workaround for this is to run the commands that load kernel image with an argument that defines the size.

 

However, this mitigation fails if the binary image is loaded from a network location using the Trivial File Transfer Protocol (TFTP). The reason is that the command used for running the image does not support arguments to restrict the maximum size of the file.

 

Although Barisani ran tests only on U-Boot version 2018.09-rc1, he believes that all versions of the software are vulnerable to attacks similar to the ones he described. He notes that lack of protection at loading binaries makes U-Boot susceptible to variants of the technique he described because other image loading functions are likely to fall short on validation issues as well.

 

Source