The Boot process is what actually brings up the Operating System once the computer is starting up. GRUB and UEFI are primary examples of this.
Why is this important for security? If this is compromised, then there is NO trust on what is running on the OS, drivers or anything else that is being ran on the computer.
To enforce this, the boot process keeps a list of
cryptographic signatures to verify if a piece of code should be allowed to run or not. There are two DBs: one that allows certain components and one that specifically disallows. Additionally, these certificates (used for signing) derive from the Microsoft Root Certificate. For more information the chain of trust for bootloaders, please visit
here.
With the background out of the way, we can dive into the bug! The vulnerability is one that is just as old as computers: a classic buffer overflow. The vulnerability occurs in the grub.cfg file, which has configurations for the bootloader to use. The file is a good target because it is not signed (because it SHOULD be changeable) and is alterable from an administrative user.
This file gets parsed as a Domain Specific Language (DSL) uses flex and bison to generate a parsing engine for a domain-specific language (DSL) from language description files and helper functions.Although this is great and all (as it is much more modular), a dynamic language interpreter is going to be vastly complex.
What's the error exactly? The interpreter expects for all error messages being called to exit. However, instead, it logs something to console and continues execution. Because the execution continues with unexpected values, there are many places for memory corruption.
It should also be noted that the Bootloader does not have modern memory protections to defend against attackers, such as NX and ASLR. So, once an overflow has been found, it is trivial to jump to shellcode and control the flow of execution.