Servers at risk from “BootHole” bug – what you need to know

Another month, another BWAIN!
That’s our tongue-in-cheek name for a cybersecurity vulnerability that not only gets assigned an identifier like CVE-2020-10713, but also acquires an impressive name plus a jaunty logo (and even, in one intriguing case, a theme tune).
This month’s bug with an impressive name (see what we did there?) is called BootHole, and its logo rather cheekily shows a boot with a worm sticking out of a hole in the toecap.
The bad news is that this bug affects the integrity of bootup process itself, meaning that it provides a way for attackers to insert code that will run next time you restart your device, but during the insecure period after you turn on the power but before the operating system starts up.
The good news for most of us is that it relies on a bug in a bootloader program known as GRUB, short for Grand Unified Boot Loader, which is rarely found on Windows or Mac computers.
The bad news for the sysadmins among us, however, is that GRUB (more precisely, GRUB2, but it’s often just referred to as GRUB) is the default bootloader used by several popular Linux distros these days.
In other words, if you have a rack of Linux servers somewhere, whether that’s a physical rack in your own server room or a virtual rack in a cloud service, you may have lots of important computers that are – in theory at least – at risk.
By the way, the logo that we referred to above as “cheeky” – because it features a worm – might be taken to imply that this is an wormable security hole.
A wormable hole would mean that a crook who could infect one of your servers with malware exploiting this bug might be able to kick off a self-spreading feature that automatically dissemimated the malware to other servers in the same rack, or perhaps even further afield.
We don’t want to say that’s impossible, because we can envisage server setups where you might just about be able to pull off that sort of caper in a pre-boot environment, but we think it’s unlikely.
Generally speaking, an attacker will almost certainly need to have superuser (root) access to your computer up front in order to exploit this vulnerability.
If you need to be logged in as root to start with, there’s no unauthenticated remote code execution (RCE) hole, which we assume is why Linux vendor Red Hat has given this bug a severity impact of Medium rather than High or Critical, even though it affects the boot process and could give attackers a way to implant malware that manipulates the operating system itself.

The bootup process

In the early days of PCs, the bootup process was almost totally unprotected.
When the power was turned on, the CPU ran a small program called the BIOS, short for Basic Input Output System, out of ROM, short for read-only memory. (This part was pretty secure, because the ROM firmware could only be changed by opening up the case and swapping out a special chip on the motherboard.)
The BIOS then blindly read 512 bytes from the first physical sector of the hard disk into a known location in RAM – memory addresses 0x07C00 to 0x07DFF, if you are interested – to act as the bootloader program.
If the last two bytes of that 512-byte sector were 0x55AA (chosen because it’s 01010101 10101010 in binary), known as the boot signature, it was assumed to be a legitimate bootloader and the BIOS then jumped directly to address 0x07C00 (0000:7C00 in 16-bit segment notation), and the bootup sequence commenced.
And that was that – the master bootloader code was supposed to locate the bootable partition, load a secondary boot sector from there, perform some basic verification of its own and hand over control in turn, whereupon the secondary boot sector would find the operating system kernel and load it, and so the process would continue.
This process is known as bootstrapping to this day, from the idea of “pulling yourself up by your bootstraps” – an impossibility in real life, thanks to Newton’s Laws of Motion, but nevertheless a metaphor in the English language for working yourself up into an influential position from humble beginnings.
Of course, in the old days, the boot sector could contain anything, and frequently did.
Corruption caused by writing to sector zero by mistake would typically leave your PC unbootable, while deliberate infection of the boot sector by viruses led to years’ worth of trouble caused by boot sector viruses with redolent names such as Stoned, Angelina and Michelangelo.
Notably, because the boot sector runs before your operating system – indeed, the operating system relies on the boot sector to load in the first place – it runs before any operating system protections are in place.
There’s no memory protection, no idea of privileged processes, no concept of user and superuser (also known as the root or administrator account), no access control lists on files or directories, nothing.
So crooks often used the boot sector to hide away hacking tools such as rootkits, malware programs that are specifically devised to disguise or conceal other malware by interfering with the operating system “from underneath”.

Adding in security

To protect the bootup process, most modern computers – whether they’re laptops, servers, NUCs or whatever – have a feature called Secure Boot, and on most devices it’s turned on by default.
The BIOS is replaced by a system called UEFI, short for universal extensible firmware interface, which isn’t blindly trusting like the BIOS process was. (Actually the BIOS still is there: you can turn most computers back into BIOS mode, also called legacy mode, if you want, but you typically need physical access to the computer to make the switch.)
In Secure Boot mode, the various stages of the bootstrap process are verified using digital signatures, based on cryptographic keys stored on the motherboard before the device is shipped. (On most computers you can replace these keys with your own to take control of the signing process, but once again you need physical access to do so.)
When you boot with GRUB, the process usually involves a chain of loading and digital signature checking that works a bit like this:

• Verify the UEFI firmware.
• Use the firmware to load the main bootloader.
• Verify the main bootloader, which on Linux systems is probably an intermediate bootloader called shim or PreLoader that is signed by Microsoft, whose signing key your computer hardware probably already trusts.
• Use the shim or PreLoader bootloader to load the GRUB bootloader, which is typically signed by the creator of your Linux distro.
• Verify the GRUB bootloader.
• Read in a text-based configuration file and present a bootloader menu.

The digital signatures make it hard for crooks to replace any of the bootloader programs, which helps to keep boot sector viruses and rootkits out of your system – it’s difficult for the crooks to insert low-level code that runs before the operating system and might therefore be able to subvert it right from the start.
You can guess where this is going, can’t you?

Text files can be harmful

That text-based configuration file we mentioned above isn’t digitally signed – at least, it isn’t checked by GRUB itself, and in most Linux distros there is apparently no additional process for validating the file before the operating system loads.
And the BootHole vulnerability is a parsing error in the GRUB bootloader that leads to a buffer overflow while the configuration file is being read in.
Oh no!
Text files are supposed to be pure data, but by feeding the GRUB bootloader a line that’s far too long, it seems that you can not only crash the bootloader code, but also wrangle control back from it, causing code execution to continue inside the data that just got read in from the text file.
Eclypsium, the company that found this vulnerability, reports that it’s the sort of bug that you might call a “comedy of errors”.
GRUB correctly detects that the line is too long for the buffer, catches the error, faithfully reports it where you might just about notice it pop up on the console if you were looking at the screen at exactly the right instant…
…and then ignores the error and carries on anyway.
Simply put: anyone who has root-level access to your computer, and can write text into the GRUB.CFG file, can sneak in bootloader code – what’s known as shellcode in the jargon – via that text file.
But because the text file is considered “mostly harmless”, in the words of the HHGttG, it is not subjected to the same digital signature controls as the other files that are part of the secure bootstrap process.
In other words, crooks can implant arbitrary bootloader code that will run next time you restart your computer, before the operating system starts up, without bothering about digital signatures.
Unfortunately, buffer overflows of this sort in bootloader code are almost always exploitable by attackers, because the comparative simplicity of the UEFI environment means that a lot of the exploit prevention mechanisms that modern operating system provide simply don’t exist.
During the bootstrap process, there are no protections such as Data Execution Prevention (which helps to stop data in an overflowed buffer from being executed at all) and Address Space Layout Randomisation (which makes it hard to grab control successfully even if you can reliably provoke a program crash).
If you’re a programmer then, in the world of bootloaders, it’s like 1984 all over again.

What to do?

Apparently, Eclypsium’s bug report prompted not just a bug fix in GRUB but a code review looking for other smilar coding errors, given the extra severity of buffer overflows in the bootloader world.
So the GRUB team has removed not only this bug (CVE-2020-10713) but also seven more, denoted CVE-2020-14308, CVE-2020-14309, CVE-2020-14310, CVE-2020-14311 CVE-2020-15705,CVE-2020-15706 and CVE-2020-15707.
With this in mind:

• Check your Linux distro for an update to GRUB if you use it. If you don’t need the size and complexity of GRUB, you might consider switching to a different bootloader.
• Consider monitoring your GRUB.CFG files for unauthorised modifications. If you don’t already have tools for doing this sort of thing, check out the command inotifywait. But remember that a criminal with root access to overwrite the GRUB configuration file in the first place might be able to turn off or bypass your change monitoring anyway.
• Review who has root-level access to your servers. You should do this anyway, and regularly, as much to prevent accidents as to keep crimimals out.
• Use 2FA whenever you can. This makes it easier to make sysadmins individually accountable, which protects them as much as it protects you, and it stops crooks using simple phishing or keylogging tricks alone to recover passwords.

Note that if you aren’t using Secure Boot, then your bootloader code isn’t protected by digital signature checking anyway, but it’s still worth considering all these tips, because it’s probably easier for crooks to mess with your bootloader via GRUB.CFG than by using low-level techniques to write to the bootloader files and disk sectors directly.
We suspect that there won’t be many computers out there that are pure-play Windows or Mac devices – ones that don’t have a Linux partition at all – running GRUB, but even if you aren’t affected directly by this bug…
…take heed of tips 3 and 4 anyway, because they’re good advice for everyone!

A final observation

As a commenter pointed out (see @Gabriel’s comment below), an attacker with physical access to your laptops or servers could, if booting from external devices is enabled, use a “pre-infected” Linux USB drive – one rigged out with a booby-trapped GRUB setup – as a way to run unsigned bootloader code on, say, a Windows computer.
This isn’t a big deal if anyone with physical access is already able to access your computer’s setup screen at power-up time, because if that were the case they could almost certainly just turn Secure Boot off temporarily anyway, and wouldn’t need to make use of the vulnerability.
But on work computers where access to the setup screen is turned off (so that only IT can tweak the system configuration) but booting from USB is turned on (for example, to allow remote users to assist with troubleshooting in emergencies), the BootHole bug could indeed be used as a Secure Boot bypass trick.
This means that an attacker with physical access might be able to access your computer as though Secure Boot were turned off, without opening up the device and extracting the hard disk or using any other intrusive or time-consuming techniques.
There are two mitigations we can think of here:

• Turn off booting from external devices. Many IT departments already do this as a general security precaution on business laptops that support secure lockdown of the computer’s setup screen. Note, however, that if the setup screen password protection offered by the manufacturer really is secure, even the vendor can’t bypass it if you forget the unlock code. (Lenovo business laptops work that way: a lost setup password means replacing the motherboard – and that is a feature, not a bug!)
• Keep your eyes open for updates for your computer’s own operating system and firmware, even if you don’t run Linux. Secure Boot uses both an allowlist of known-good bootloader signing keys, and a blocklist of known-bad ones so that keys used to sign used rogue or buggy bootloaders can be retired. These updates often take a long time to show up, however, because all bootloaders ever signed with the key being retired need to be re-signed and re-issued first, even those with no bugs that would not otherwise need updating.