Category Icon
security
|
27.01.2025

Filesystem Vulnerabilities in Bootloaders: A Hidden Risk for Verified Boot Mechanisms

In modern IoT systems, particularly those using Linux-embedded devices, ensuring the integrity and trustworthiness of the boot process has become increasingly critical. Verified boot mechanisms, often referred to as trusted or secure boot, serve as the cornerstone of device security by guaranteeing that only signed and authenticated code is executed during the boot process. This mechanism is vital for protecting sensitive functions such as data encryption, authentication, and the overall integrity of IoT devices.

It’s important to recognize that if your IoT system does not implement verified boot, the identified vulnerabilities may not pose a direct risk. In such cases, attackers can manipulate persistent program code at any time, rendering those specific vulnerabilities irrelevant.

Introduction

The verified boot process ensures that each stage of the system’s boot sequence is authenticated and trusted. At a high level, the process involves the following steps:

  1. Boot ROM Validation: The system-on-chip (SoC)’s boot ROM initiates the boot process by loading a signed bootloader, establishing the first layer of trust.
  2. Bootloader Verification: The bootloader, commonly U-Boot or Barebox, loads critical components such as the Linux kernel, device tree, and initramfs from the filesystem, verifying their signatures to ensure authenticity.
  3. Linux Execution: Once the verified kernel is booted, the system executes the application code. The Linux kernel continues enforcing security by authenticating files loaded from the filesystem.

This sequence forms a chain of trust, where each stage verifies the integrity of the next. If any part of this chain is compromised, attackers could gain the ability to execute arbitrary code, extract sensitive data, or impersonate the device. Such vulnerabilities pose significant risks, as they allow adversaries to install malicious code on the device whenever sufficient access is obtained.

Critical Code Paths

Every step in the chain of trust involves processing and validating potentially malicious input. For instance, the boot ROM often parses a SoC vendor-specific data structure containing the bootloader and its signature. A vulnerability in this code path could allow attackers to bypass the chain of trust and execute arbitrary code. Such vulnerabilities have been identified in the boot ROM of certain NXP SoCs.

Another well-known critical point is the bootloader. Depending on the bootloader and operating system, essential files like the kernel or configuration files must be parsed and verified. An example of a vulnerability in this area is the infamous BootHole flaw in the GRUB2 bootloader, which exposed systems to significant security risks.

Filesystem Vulnerabilities in Bootloaders: A Hidden Risk

Bootloaders such as U-Boot and Barebox are widely used in IoT systems because of their maturity, rich feature sets, and strong community support. Both bootloaders incorporate robust mechanisms for verified boot, enabling them to authenticate the files they load, including the kernel and configuration files.

However, an initial audit of their verified boot implementations has revealed a frequently overlooked vulnerability: the filesystem implementation itself.

Filesystems as a Threat Vector

Most bootloaders support a variety of filesystems, such as ext4, FAT, SquashFS, and UBIFS. However, these implementations are often ad hoc and lack key features. This is primarily because bootloaders operate in highly constrained environments, with no support for concurrency and access to minimal resources. As a result, complete filesystem implementations are unnecessary for bootloaders; they only need to be functional enough to read files from a filesystem, nothing more.

A key task of a filesystem implementation is to parse the filesystem data structures stored on a storage medium, interpret them meaningfully, and present the logical files to higher layers. In a verified boot setup using bootloaders like U-Boot or Barebox, while the contents of files are authenticated, the filesystem data structures themselves are typically not. This opens an attack vector where an attacker could craft malicious filesystem structures that bypass authentication checks and exploit bugs in the filesystem driver implementation. By corrupting filesystem metadata, attackers can compromise the chain of trust, enabling arbitrary code execution or further exploitation.

We have identified the following vulnerabilities that are directly or indirectly associated with filesystem implementations in the Barebox and U-Boot bootloaders:

  • CVE-2024-57254: Integer overflow in U-Boot’s SquashFS symlink size calculation function
  • CVE-2024-57255: Integer overflow in U-Boot’s SquashFS symlink resolution function
  • CVE-2024-57256: Integer overflow in U-Boot’s ext4 symlink resolution function
  • CVE-2024-57257: Stack overflow in U-Boot’s SquashFS symlink resolution function
  • CVE-2024-57258: Multiple integer overflows in U-Boot’s memory allocator
  • CVE-2024-57259: Heap corruption in U-Boot’s SquashFS directory listing function
  • CVE-2024-57260: Multiple vulnerabilities in Barebox’s SquashFS due to missing patches from Linux
  • CVE-2024-57261: Integer overflow in Barebox’s memory allocator
  • CVE-2024-57262: Integer overflow in Barebox’s SquashFS symlink resolution function

As of this writing, all identified issues have been resolved in Barebox version v2025.01.0 and U-Boot version v2025.01-rc1.

The vulnerabilities allow an attacker with access to the storage medium to modify filesystem structures in a manner that enables the execution of untrusted code. CVE-2024-57256, in particular, is a significant target, as it provides an attacker with essentially unrestricted access to U-Boot’s memory. Some might question the relevance of CVE-2024-57257 and CVE-2024-57258 in this attack scenario. Both Barebox and U-Boot allocate buffers to store filesystem data, with the buffer sizes determined by the size attributes of the filesystem structures. Since attackers can manipulate these size attributes, they can trigger integer overflows in the memory allocators. This leads to buffer overflows when the allocators allocate less memory than required for the copied data.

Impact of These Vulnerabilities

The impact of these vulnerabilities varies depending on your threat model, ranging from none to critical. If you are not using any verified boot technology, these vulnerabilities are unlikely to pose a security issue for you. However, if the integrity of your product relies on verified boot mechanisms, an attacker could potentially exploit these vulnerabilities to compromise the chain of trust.

The Situation on Linux

One might wonder about the situation on Linux. A filesystem implementation bug in Linux would, of course, also be problematic. However, the situation on Linux is generally better for two key reasons:

  • Better Testing: Filesystems in Linux undergo more rigorous testing, including regular fuzz testing, which helps uncover and fix potential bugs. AFL fuzz testing uncoverered many bugs in Linux.
  • Enhanced Protection: In a verified boot setup, filesystems used by the Linux kernel are typically protected by mechanisms like dm-verity or dm-integrity. These provide full filesystem integrity in addition to encryption. As a result, a crafted filesystem would be detected early at the block layer, mitigating the risk of exploitation.

Conclusion

As IoT systems continue to proliferate, ensuring the integrity of the verified boot process becomes increasingly critical. Filesystems, often overlooked in the chain of trust, can represent a significant vulnerability in bootloader security. We hope that filesystem implementations in bootloaders receive more thorough testing in the future to enhance their robustness and reliability.

Publish date

27.01.2025

Category

security

Authors

Richard Weinberger

Icon with a waving hand

Get in touch

+43 5 9980 400 00 (email preferred)

sigma star gmbh
Eduard-Bodem-Gasse 6, 1st floor
6020 Innsbruck | Austria

LinkedIn logo
sigma star gmbh logo