‘If you compromise the bootloader, you pwn the whole phone’
4 min read

‘If you compromise the bootloader, you pwn the whole phone’

‘If you compromise the bootloader, you pwn the whole phone’

TOKYO—In the deepest, darkest recesses of all computer-powered devices, from your phone to your laptop to your smart thermostat to even your car, lies one of their most important software components: the bootloader.

The bootloader serves multiple purposes in making the computer work for its end users, including communicating with keyboards and mice, USB sticks and disk drives, monitors, and networking cards. Hackers, historically, have not commonly targeted bootloaders. But new research revealing more than two dozen zero-day vulnerabilities in bootloaders suggests that they might soon. These ready-to-exploit holes, located at the foundation of our digital world, aren’t easy to patch.

The vulnerabilities, discovered by Ilja van Sprundel and Joseph Tartaro at security research company IOActive, and by Andrea Barisani at antivirus company F-Secure, affect a wide range of bootloaders, including Das U-Boot, Coreboot, Grub, Seabios, CFE, iPXE, and TianoCore, they disclosed at PacSec 2019 here in November. The IOActive team found 13 zero-day vulnerabilities in U-Boot alone.


RCS delivers new texting features—and old security vulnerabilities
Have a Tesla Model 3? This app can track its location
Pwned Android, Chromium devices drive winnings at Tokyo hacker contest

These open-source bootloaders are not household names, but many products they support are: Android devices, ARM-based Chromebooks, Amazon Kindle devices, Lenovo and Asus computers, Apple Airports, Asus routers, Linksys Wi-Fi routers, and LG and Samsung TVs.

The risks from these vulnerabilities strike at the core of digital insecurity, says Tartaro, a senior security consultant for IOActive. “The bootloader is the key foundation for your chain of trust. If you find a bug” in the bootloader that lets you run malicious software, “you can compromise everything past that. All security is ensured by what happens before it.”

Representatives of Microsoft, Apple, Amazon, Google, Coreboot, Grub, and TianoCore did not return requests for comment.

“Every time we looked at a Secure Boot implementation, we broke it.”—Andrea Barisani, head of hardware security, F-Secure.

Tom Rini, chief custodian of the Das U-Boot software, acknowledged in an email to The Parallax that bootloader vulnerabilities are a “potentially large” security problem because of competing interests in bootloader development: Some developers want more features; some want fewer. That tension “ends up leading to having to put faith in the chain of trust rather than sanitize every input, and that leads to failure,” he wrote.

The attacks that Tartaro and van Sprundel demonstrated varied by bootloader and device, but covered what they described as “common” hacks. Some required physical access to the device; others could be run remotely; and at least one involved DNS spoofing, first documented in the early 1980s.

“Some device makers are poor at hardening, or limiting attack surface. Engineers also underestimate reverse-engineering attacks, or presume that there are no bad actors,” Tartaro says.

Barisani, the head of hardware security research at F-Secure, looked for vulnerabilities in Secure Boot, an anti-malware component of UEFI that began replacing the traditional BIOS in Windows 8, and makes the booting process more secure. A mandatory feature of Windows 10 installations, it has helped and hindered Windows security.

“Every time we looked at a Secure Boot implementation, we broke it,” Barisani says. He declined to be more specific, citing ongoing outreach between F-Secure and affected vendors prior to public disclosure. “Dozens” of implementations are affected, he says.

“Doing Trusted Boot or Secure Boot is hard because you have many layers, and they all need to be secure to not break the chain of trust,” Barisani adds. “These flaws were common in software 15 years ago, but the state of security in bootloaders is very low. The actual exploits are not very refined. This is worrying. More emphasis and more awareness should be placed on these kinds of issues.”

Overview of the Trusted/Verified Boot implementation according to the ARM and Google specifications. Between parentheses the name of the internal storage partition where the code is located in a typical implementation. Image courtesy Bootstomp PDF.

Fixing bootloader vulnerabilities is more complicated than simply writing a software patch for what ails them and shipping it out. Some devices do not have a simple over-the-air mechanism for delivering update patches, though many (such as smartphones) now do. But because physical access is often (but not always) required to exploit a bootloader vulnerability, vendors often ignore the need to patch those security flaws.

“As to if vulnerabilities are largely preventable or not, some classes of problems certainly are preventable. But it’s always been and will always be ‘whack-a-mole,’” U-Boot’s Rini said in his email.

While bootloader exploits may not be the go-to attack for hackers targeting a consumer’s bank account, they pose a much greater risk to organizations (and their employees) subject to political or industrial espionage, van Sprundel says.

Locking down bootloaders should be relatively easy for vendors that take the vulnerabilities seriously, he says. But the fact that the bootloader security problems he, Tartaro, and Barisani recently documented have had available patches since the 1990s points to larger issues with security testing during a device’s supply chain.

Nilo Redini, one of the lead researchers on BootStomp, a 2017 research paper that divulged six zero days in four bootloaders, says bootloader security vulnerabilities are often created by poor security testing on the part of manufacturers that “don’t follow” guidelines. Things become exceptionally risky when they install single-stage bootloaders on high-value devices like a smartphones, where security fragmentation prevents many devices from receiving otherwise-available updates.

“If you compromise the bootloader, you pwn the whole phone,” Redini says.

Ultimately, bootloader security resembles Swiss cheese because of a lack of emphasis on securing the software and hardware supply chains, he says. As more security experts turn their attention to the intersection of software and hardware, more research finds what van Sprundel calls a “shocking number” of vulnerabilities that should have been patched before the products shipped to consumers.

Tartaro and van Sprundel started researching bootloader security not because of a new client at IOActive, but because they were bored on a CalTrain ride to a San Francisco Giants game in June. Within 45 minutes, van Sprundel says, they were able to detect bootloader vulnerabilities and lay out their presentation here.

“Most software is not a static thing. So even if the most obvious thing in your project was audited five years ago, it may no longer be secure,” he says. “Software security needs recurring reviews. Security is a process, not an end point.”

Disclosure: PacSec’s organizers covered part of The Parallax’s conference travel expenses.

Enjoying these posts? Subscribe for more