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.
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:
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.
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.
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.
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:
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.
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.
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:
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
+43 5 9980 400 00 (email preferred)
sigma star gmbh
Eduard-Bodem-Gasse 6, 1st floor
6020 Innsbruck | Austria