{"id":58401,"date":"2025-03-31T16:00:00","date_gmt":"2025-03-31T16:00:00","guid":{"rendered":"https:\/\/www.threatshub.org\/blog\/analyzing-open-source-bootloaders-finding-vulnerabilities-faster-with-ai\/"},"modified":"2025-03-31T16:00:00","modified_gmt":"2025-03-31T16:00:00","slug":"analyzing-open-source-bootloaders-finding-vulnerabilities-faster-with-ai","status":"publish","type":"post","link":"https:\/\/www.threatshub.org\/blog\/analyzing-open-source-bootloaders-finding-vulnerabilities-faster-with-ai\/","title":{"rendered":"Analyzing open-source bootloaders: Finding vulnerabilities faster with AI"},"content":{"rendered":"

By leveraging Microsoft Security Copilot <\/a>to expedite the vulnerability discovery process, Microsoft Threat Intelligence uncovered several vulnerabilities in multiple open-source bootloaders, impacting all operating systems relying on Unified Extensible Firmware Interface (UEFI) Secure Boot as well as IoT devices. The vulnerabilities found in the GRUB2 bootloader (commonly used as a Linux bootloader) and U-boot and Barebox bootloaders (commonly used for embedded systems), could allow threat actors to gain and execute arbitrary code.<\/p>\n

Using Security Copilot, we were able to identify potential security issues in bootloader functionalities, focusing on filesystems due to their high vulnerability potential. This approach saved our team approximately a week\u2019s worth of time that would have otherwise been spent manually reviewing the content. Through a series of prompts, we identified and refined security issues, ultimately uncovering an exploitable integer overflow vulnerability. Copilot also assisted in finding similar patterns in other files, ensuring comprehensive coverage and validation of our findings. This efficient process allowed us to confirm several additional vulnerabilities and extend our analysis to other bootloaders like U-boot and Barebox, which share code with GRUB2. We\u2019re sharing this research as an example of the increased efficiency, streamlined workflows, and improved capabilities that AI solutions like Security Copilot can deliver for defenders, security researchers, and SOC analysts. As AI continues to emerge as a key tool in the cybersecurity community, Microsoft emphasizes the importance of vendors and researchers maintaining their focus on information sharing. This approach ensures that AI\u2019s advantages in rapid vulnerability discovery, remediation, and accelerated security operations can effectively counter malicious actors\u2019 attempts to use AI to scale common attack tactics, techniques, and procedures (TTPs).<\/p>\n

While threat actors would likely require physical device access to exploit the U-boot or Barebox vulnerabilities, in the case of GRUB2, the vulnerabilities could further be exploited to bypass Secure Boot and install stealthy bootkits or potentially bypass other security mechanisms, such as BitLocker. The implications of installing such bootkits are significant, as this can grant threat actors complete control over the device, allowing them to control the boot process and operating system, compromise additional devices on the network, and pursue other malicious activities. Furthermore, it could result in persistent malware that remains intact even after an operating system reinstallation or a hard drive replacement.<\/p>\n

We disclosed these vulnerabilities with the GRUB2, U-boot, and Barebox maintainers and worked with the GRUB2 maintainers to contribute fixes for the discovered vulnerabilities. To address the issues, the GRUB2 maintainers released security updates<\/a> on February 18, 2025, and both the U-boot and Barebox maintainers released updates on February 19, 2025. We thank the GRUB2, U-boot, and Barebox maintainers as well as the open-source community for their quick response and collaborative efforts in addressing these issues, and we advise users to ensure their instances are up to date. We would also like to thank the RedHat support team for their assistance in disclosing these issues to manufacturers. The respective vulnerabilities are summarized in the following table:<\/p>\n

<\/figure>\n

In this blog, we detail how Secure Boot and GRUB2 function, explain how the GRUB2 vulnerabilities could have been exploited, and provide information on the vulnerabilities found in other open-source bootloaders to highlight the risks associated with unknowingly sharing vulnerable code among different open-source projects. As the boot process involves multiple components spanning different manufacturers and vendors, updates and fixes to the Secure Boot process can be particularly complex and run the risk of rendering a device unusable. As such, we are also sharing these findings with the security community to emphasize the importance of responsible disclosure and collaboration in the effort to enhance protection technologies and security across different devices and platforms.<\/p>\n

Secure Boot and GRUB2<\/h2>\n

Before 2006, Intel-based computers booted into startup firmware code commonly known as the BIOS (Basic Input\/Output System)<\/a>, which was responsible for hardware initialization and setup of common services to later be used by a bootloader<\/a>. Ultimately, the BIOS would transfer control to a bootloader coded in real mode, which would commonly load an operating system (OS).<\/p>\n

With time, attackers realized there is no root-of-trust verification of bootloaders by the firmware, thus began the era of bootkits<\/a>, which are bootloader-based rootkits. To standardize the boot process, a unified firmware schema to replace BIOS was introduced in 2006, which is currently known as the Unified Extensible Firmware Interface (UEFI)<\/a>.<\/p>\n

UEFI also helped combat bootkits, as it offers services that validate bootloaders and its own extensible modules by means of digital signatures. That protocol is known as Secure Boot<\/a> and is essential to establishing a root of trust for the boot process, in which the firmware verifies UEFI drivers and OS modules with a platform key<\/em> or a Key Exchange Key<\/em>, and bootloaders verify the loaded operating system.<\/p>\n

Trust is then achieved with the help of equipment manufacturers, which can sign code trusted by Secure Boot, by means of Certificate Authorities (CA). Essentially, manufacturers sign code with their private key, and their public key is signed with a root CA, commonly Microsoft\u2019s UEFI CA<\/a>. This is also essential to supporting non-Windows bootloaders such as GRUB2 (which commonly boots Linux) and allowing third party operating systems to benefit from Secure Boot. Since GRUB2 is fully open-sourced, vendors install a small program called a shim<\/a>, which is signed by Microsoft\u2019s UEFI CA and is responsible for validating the integrity of GRUB2. The shim can further consult a mechanism called Secure Boot Advanced Targeting (SBAT)<\/a> for further revocation and management options as SBAT is used by the shim to provide a way to track and revoke individual software components based on metadata rather than cryptographic signatures alone.<\/p>\n

\"A
Figure 1. GRUB2 loading schema<\/em><\/figcaption><\/figure>\n

The dangers of a GRUB2<\/h2>\n

Since bootloaders run before operating systems run, they mostly have UEFI-provided services as APIs to rely on. Therefore, bootloaders do not benefit from modern operating system security features, such as:<\/p>\n