user/grub: multiple vulnerabilities
|Alias(es)||CVE-2020-10713, CVE-2020-14308, CVE-2020-14309, CVE-2020-14310, CVE-2020-14311, CVE-2020-15705, CVE-2020-15706, CVE-2020-15707, boothole|
|Reporter||Max Rees (sroracle)|
|Assignee||Max Rees (sroracle)|
|Reported||2020-07-30 17:06:40 -0500|
|Modified||2020-07-30 17:06:40 -0500|
|Hardware||Adélie Linux / All|
|Importance||--- / normal|
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.
In grub2 versions before 2.06 the grub memory allocator doesn't check
for possible arithmetic overflows on the requested allocation size.
This leads the function to return invalid memory allocations which can
be further used to cause possible integrity, confidentiality and
availability impacts during the boot process.
There's an issue with grub2 in all versions before 2.06 when handling
squashfs filesystems containing a symbolic link with name length of
UINT32 bytes in size. The name size leads to an arithmetic overflow
leading to a zero-size allocation further causing a heap-based buffer
overflow with attacker controlled data.
Integer overflow read_section_from_string may lead to heap based
same as previous
Integer overflow in grub_ext2_read_link leads to heap based buffer
same as previous
GRUB2 fails to validate kernel signature when booted directly without
shim, allowing secure boot to be bypassed. This only affects systems
where the kernel signing certificate has been imported directly into
the secure boot database and the GRUB image is booted directly without
the use of shim. This issue affects GRUB2 version 2.04 and prior
There doesn't seem to be an official fix for this.
- Debian is ignoring it (not affected)
- Ubuntu & SUSE: https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/plain/debian/patches/0097-linuxefi-fail-kernel-validation-without-shim-protoco.patch?h=focal&id=62887dc0030652f9bc20f3d558565ca3e37ef5a6 https://bugzilla.suse.com/attachment.cgi?id=839944&action=diff
GRUB2 contains a race condition in grub_script_function_create()
leading to a use-after-free vulnerability which can be triggered by
redefining a function whilst the same function is already executing,
leading to arbitrary code execution and secure boot restriction
bypass. This issue affects GRUB2 version 2.04 and prior versions.
Integer overflows were discovered in the functions grub_cmd_initrd and
grub_initrd_init in the efilinux component of GRUB2, as shipped in
Debian, Red Hat, and Ubuntu (the functionality is not included in
GRUB2 upstream), leading to a heap-based buffer overflow. These could
be triggered by an extremely large number of arguments to the initrd
command on 32-bit architectures, or a crafted filesystem with very
large files on any architecture. An attacker could use this to execute
arbitrary code and bypass UEFI Secure Boot restrictions. This issue
affects GRUB2 version 2.04 and prior versions.
There are reports that these changes were making systems unbootable, but
at least for RedHat that appears to have been a problem with their
signed shim. However, given the extensive changes these entail (and the
fact that they will probably not apply cleanly to 2.04, and that we
don't really support secure boot right now anyway) means we should sit
on this for the time being.