Moderate
CVE-2020-10713 - BootHole
Add Reference
Description
URL
Type
Moderate
(2 users assessed)
High
(2 users assessed)None
High
Local
CVE-2020-10713 - BootHole
MITRE ATT&CK
Collection
Command and Control
Credential Access
Defense Evasion
Discovery
Execution
Exfiltration
Impact
Initial Access
Lateral Movement
Persistence
Privilege Escalation
Description
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.
Add Assessment
Ratings
-
Attacker ValueLow
-
ExploitabilityHigh
Technical Analysis
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.
Ratings
-
Attacker ValueHigh
-
ExploitabilityMedium
Technical Analysis
A buffer overflow exists within GRUB2 affecting how it handles it’s configuration file. An exception occurs when the contents of the configuration are too large for the buffer that is incorrectly handled causing the contents to be written anyways, thus over flowing the buffer.
In order to exploit this, an attacker would likely need either:
- Physical access to an affected device and sufficient time to mount the disk and corrupt / infect the GRUB configuration file
- Administrative access to running system to corrupt / infect the GRUB configuration file
Successful exploitation of this vulnerability could corrupt the secure boot process and compromise the integrity of the system over all. This would effectively allow the installation and utilization of a bootkit. Developing a weaponized exploit would be aided by the lack of modern memory protections such as address space layout randomization (ASLR).
Patching is a complicated process involving updating the firmware from the vendor and applying a denylist which must be done manually (for now at least).
For more information see the Grubbing Secure Boot the Wrong Way: CVE-2020-10173.
General Information
Products
- Grub
References
Advisory
Additional Info
Technical Analysis
Report as Exploited in the Wild
What do we mean by "exploited in the wild"?
By selecting this, you are verifying to the AttackerKB community that either you, or a reputable source (example: a security vendor or researcher), has observed an active attempt by attackers, or IOCs related, to exploit this vulnerability outside of a research environment.
A vulnerability should also be considered "exploited in the wild" if there is a publicly available PoC or exploit (example: in an exploitation framework like Metasploit).
If you’re curious about the cloud environment issue, it’s interesting because it’s hard to find vendors that say something that sounds scary like ‘we don’t support secure boot’, which makes sense. Folks would equate that to ‘not secure’. But if you read between the lines, basically AWS does a neat trick if you do try to boot with a GPT / UEFI partition. It silently swaps in an MBR partition instead, signalling to your OS implicitly to disable secure boot. In the end, even if they did support secure boot, you’d have to trust them anyway (they can see all of your memory and disk after all). You can check here for details, other cloud providers may have similar fine print: https://docs.aws.amazon.com/vm-import/latest/userguide/vmie_prereqs.html
I’d love to hear that there is a way to basically get a chain of trust when you don’t own the hardware, just to know folks are thinking about how to implement zero-trust with cloud providers, but it seems like you’d have to send them your own custom TPM modules to establish your own personal chain of trust.
I caught this interesting info from Trammell Hudson today, where there are experimental patches to enable Secure Boot from Xen. https://safeboot.dev/faq/#does-safeboot-work-with-qubes-or-xen
The above site is also super handy just for understanding the whole Secure Boot landscape, where it fails and how to make it work in general.