CVE-2020-10713 - BootHole

A flaw was found in grub2, prior to version 2.06. An attacker may use the GRUB 2 flaw to hijack and tamper the GRUB verification process. This flaw also allows the bypass of Secure Boot protections. In order to load an untrusted or modified kernel, an attacker would first need to establish access to the system such as gaining physical access, obtain the ability to alter a pxe-boot network, or have remote access to a networked system with root access. With this access, an attacker could then craft a string to cause a buffer overflow by injecting a malicious payload that leads to arbitrary code execution within GRUB. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

Recent assessments:

busterb at August 05, 2020 6:48pm UTC reported:

If you actually have a working Secure Boot installation in the first place and rely on it, yes this is a problem.

However, whether that is true is specific to your environment. Many cloud environments (like AWS), do not support secure boot/UEFI in the first place, so there’s no point to worrying about this; an attacker could just replace your grub binary already, or kernel, or anything else. You’re better off monitoring VM reboots for this kind of attack, and reprovisioning if that happens. Since this is basically a persistence mechanism, it seems like there are lot of other lower-hanging mechanisms that could also work. By the time you’ve bothered getting root or physical access, you could do so much else in the mean time. I can’t imagine this being in the top 50 things an attacker would try to do, outside of a supply chain attack of some sort.

zeroSteiner at July 29, 2020 9:00pm UTC reported:

If you actually have a working Secure Boot installation in the first place and rely on it, yes this is a problem.

However, whether that is true is specific to your environment. Many cloud environments (like AWS), do not support secure boot/UEFI in the first place, so there’s no point to worrying about this; an attacker could just replace your grub binary already, or kernel, or anything else. You’re better off monitoring VM reboots for this kind of attack, and reprovisioning if that happens. Since this is basically a persistence mechanism, it seems like there are lot of other lower-hanging mechanisms that could also work. By the time you’ve bothered getting root or physical access, you could do so much else in the mean time. I can’t imagine this being in the top 50 things an attacker would try to do, outside of a supply chain attack of some sort.

Assessed Attacker Value: 3
Assessed Attacker Value: 3Assessed Attacker Value: 4