It was reported this week by Naked Security that Linux systems are affected by a vulnerability that can render those Linux servers unbootable.
BootHole leverages a vulnerability in both GRUB2 and Secure Boot, explains TechRepublic. To make BootHole a bit more daunting, it’s actually a really easy hack to pull off. The only thing blocking ne’er do wells from making it happen is having remote access to the server. Once inside, however, all an attacker would have to do is edit the grub.cfg file in such a way as to pass a token too large for the flex parse buffer. And because grub.cfg isn’t signed, changes to the file aren’t checked.
When this happens, your Linux server won’t boot.
Of course, because this is open source, the patches came within a few days of the BootHole discovery. Those patches come in the form of shim files that can be applied.
Commenting on the news, Lamar Bailey, senior director of security at Tripwire, stated:
This vulnerability is limited to Linux based devices that us GRUB. The successfully exploit to vulnerability an attacker would need to gain root privileges then edit thee grub.cfg file to cause a buffer overflow and try to execute code. Following basic security hygiene greatly lowers the real-world risk here.
- Don’t login as Root
- Use file integrity monitoring to alert if key system fiels have been changed
- Remediate vulnerabilities
Keith Geraghty, solutions architect at Edgescan, added some further insight on how to mitigate the risk posed by this funnily named bug:
In an ideal world we shouldn’t see the word “legacy” in the boot options. Back when I used to build servers I would need to disable secure boot so I could boot into my deployment disk to kick off my build. It would be down to me to ensure I re-enable secure boot after I complete the build. Manual steps such as this can become tedious when building hundreds of devices at a time.
What’s strange is that unlike notifications for patching and insecure software we don’t get notifications from vendors to review boot options. Why is this? CISO’s should implement CIS benchmark standards well before the build process starts so that internal pipelines can be adjusted to align correctly. We also see that Boot options are typically an oversight in the QA process of a build. We need to see them front and centre. If we can’t help secure the very step for powering on a machine, we are undermining all the great work we done securing our OS, Network and Applications.
Some practical steps to take
- Ensure a BIOS review forms part of your build and QA process and ensure secure boot is on. If it’s not, ask why
- Ensure best practice such as the CIS standards are followed
- Password protect the BIOS
- Review who has root-level access to your servers
- Check regularly for updates to the GRUB Bootloader
