These days, any discussion about security starts with the root of trust. For most secure systems, this will be a secure boot based on keys stored within a system that are used to verify the code involved in booting the system. This prevents an attacker from replacing the boot code with malicious code.
The Unified Extensible Firmware Interface (UEFI) is employed on most systems these days, but one of the secure boot platforms has a hole in it. Actually, it has more than one and it’s not alone. I’m referring to CVE-2020-10713, also known as BootHole. It’s a typical buffer overrun error in GRUB2, the latest GRand Unified Boot Loader (GRUB) for Linux. The exploit is done by simply modifying a text string in a configuration file. The hack is actually a little more difficult to compute; however, once installed, the system is compromised on the next reboot.
The bug was found by researchers at Eclypsium, a security company. Their paper, “There’s a Hole in the Boot,” explains the GRUB2 vulnerability.
Getting a Grasp on GRUB2
Essentially GRUB2 is just part of the UEFI secure-boot chain that starts with firmware that uses the secure keys to verify the code at each step in the process hasn’t been compromised. The chain is needed to provide flexibility in the boot process. It allows modules to be included to handle additional hardware as well as provide more system functionality.
In a nutshell, the GRUB2 code has a bug that can be exploited whereby a malicious bootloader can be run instead of the desired boot code. The problem is that once this occurs, the operating system and any applications are essentially compromised. GRUB2 normally boots Linux, but it can provide multiple boot support that starts other operating systems like Windows.
The open-source community, including the likes of Microsoft, Red Hat, and Canonical, have worked on modifications to GRUB2 to address this particular bug. Additional bugs were found and addressed in the process of examining the security aspects of GRUB2. Updating GRUB2 on a system will fix these holes. Canonical’s GRUB2SecureBootBypass page enumerates additional GRUBS2 CVEs as well as Ubuntu versions that have the fixes.
The problem isn’t too critical as an attacker needs access to the system to modify the configuration file. This isn’t necessarily an easy remote task on a secure system. Still, it highlights the problem with a secure-boot system in that the process needs to be bug-free. Likewise, updating a system is critical when problems are detected and fixed, but this assumes that updates are made available and installed.
Too many IoT devices are utilizing connectivity strictly for the application aspect of the device with little thought given to remote updates. Secure boot in an IoT device helps to secure the device—assuming the secure boot can’t be compromised. Devices from internet gateways to smart speakers are being deployed without the benefit of upgrades, and the secure-boot aspect prevents a user from updating the system.
Developers and system administrators who deal with system installations and updates can handle these changes with relative ease. However, these things are beyond end users who aren’t even aware of the intricacies of how their device actually goes from power on to recognizing their voice commands.
