2f7a8021b5
Details: https://lists.gnu.org/archive/html/grub-devel/2020-07/msg00034.html Fixes the following security issues: * CVE-2020-10713 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. * CVE-2020-14308 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. * CVE-2020-14309 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. * CVE-2020-14310 An integer overflow in read_section_from_string may lead to a heap based buffer overflow. * CVE-2020-14311 An integer overflow in grub_ext2_read_link may lead to a heap-based buffer overflow. * CVE-2020-15706 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 * CVE-2020-15707 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. Signed-off-by: Stefan Sørensen <stefan.sorensen@spectralink.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
74 lines
2.7 KiB
Diff
74 lines
2.7 KiB
Diff
From a7ab0cc98fa89a3d5098c29cbe44bcd24b0a6454 Mon Sep 17 00:00:00 2001
|
|
From: Peter Jones <pjones@redhat.com>
|
|
Date: Wed, 15 Apr 2020 15:45:02 -0400
|
|
Subject: [PATCH] yylex: Make lexer fatal errors actually be fatal
|
|
MIME-Version: 1.0
|
|
Content-Type: text/plain; charset=UTF-8
|
|
Content-Transfer-Encoding: 8bit
|
|
|
|
When presented with a command that can't be tokenized to anything
|
|
smaller than YYLMAX characters, the parser calls YY_FATAL_ERROR(errmsg),
|
|
expecting that will stop further processing, as such:
|
|
|
|
#define YY_DO_BEFORE_ACTION \
|
|
yyg->yytext_ptr = yy_bp; \
|
|
yyleng = (int) (yy_cp - yy_bp); \
|
|
yyg->yy_hold_char = *yy_cp; \
|
|
*yy_cp = '\0'; \
|
|
if ( yyleng >= YYLMAX ) \
|
|
YY_FATAL_ERROR( "token too large, exceeds YYLMAX" ); \
|
|
yy_flex_strncpy( yytext, yyg->yytext_ptr, yyleng + 1 , yyscanner); \
|
|
yyg->yy_c_buf_p = yy_cp;
|
|
|
|
The code flex generates expects that YY_FATAL_ERROR() will either return
|
|
for it or do some form of longjmp(), or handle the error in some way at
|
|
least, and so the strncpy() call isn't in an "else" clause, and thus if
|
|
YY_FATAL_ERROR() is *not* actually fatal, it does the call with the
|
|
questionable limit, and predictable results ensue.
|
|
|
|
Unfortunately, our implementation of YY_FATAL_ERROR() is:
|
|
|
|
#define YY_FATAL_ERROR(msg) \
|
|
do { \
|
|
grub_printf (_("fatal error: %s\n"), _(msg)); \
|
|
} while (0)
|
|
|
|
The same pattern exists in yyless(), and similar problems exist in users
|
|
of YY_INPUT(), several places in the main parsing loop,
|
|
yy_get_next_buffer(), yy_load_buffer_state(), yyensure_buffer_stack,
|
|
yy_scan_buffer(), etc.
|
|
|
|
All of these callers expect YY_FATAL_ERROR() to actually be fatal, and
|
|
the things they do if it returns after calling it are wildly unsafe.
|
|
|
|
Fixes: CVE-2020-10713
|
|
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
|
|
Signed-off-by: Stefan Sørensen <stefan.sorensen@spectralink.com>
|
|
---
|
|
grub-core/script/yylex.l | 4 ++--
|
|
1 file changed, 2 insertions(+), 2 deletions(-)
|
|
|
|
diff --git a/grub-core/script/yylex.l b/grub-core/script/yylex.l
|
|
index 7b44c37b7..b7203c823 100644
|
|
--- a/grub-core/script/yylex.l
|
|
+++ b/grub-core/script/yylex.l
|
|
@@ -37,11 +37,11 @@
|
|
|
|
/*
|
|
* As we don't have access to yyscanner, we cannot do much except to
|
|
- * print the fatal error.
|
|
+ * print the fatal error and exit.
|
|
*/
|
|
#define YY_FATAL_ERROR(msg) \
|
|
do { \
|
|
- grub_printf (_("fatal error: %s\n"), _(msg)); \
|
|
+ grub_fatal (_("fatal error: %s\n"), _(msg));\
|
|
} while (0)
|
|
|
|
#define COPY(str, hint) \
|
|
--
|
|
2.26.2
|
|
|