Detailed explanation of the first CVE:
https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/

It mentions the other fixes but notes there are dozens of other fixes that weren't assigned CVEs.  It would be better if at all possible to update to the latest grub2 rather than trying to patch this.

The latter CVEs and other fixes would be the main concern for us.  The first CVE is almost a non-issue, since we don't support Secure/Restricted Boot.

*** Bug 27019 has been marked as a duplicate of this bug. ***

CC: (none) => olav

Grub2 has no consistent maintainer, so assigning this globally. Note:
> It would be better if at all possible to update to the latest grub2 rather
> than trying to patch this.
> Fixed upstream in 2.06
Current Mageia 7 version is grub2-2.02.0-15, so there is quite a jump - even from the M8 version 2.04 cited in Source RPM.

Assignee: bugsquad => pkg-bugs

Thierry backported fixes for the CVEs in grub2-2.04.0-19.mga8.  I'm guessing the other security fixes without CVEs weren't included.

CC: (none) => thierry.vignaud

Yet it might be simpler & saner to update mga7 to 2.04-1.mga7 (synced with grub2-2.04.0-19.mga8 but for release being 1)

I suppose we'll never address the other security issues in Mageia 7.  Hopefully we can ar least do so in Mageia 8.

Fedora has issued an advisory for this on September 14:
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/WPQH54SQQ5F654NLOQK55HG6HPNF7VZ4/

Fedora update for 2.02 from September 27:
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/4QPZUIYZ4VFS4VAFSITTFBWG2DZW5TUI/

As we seemingly sync with Fedora, who hasn't updated to 2.06, this will probably not be fixed soon.  To be clear, the CVEs were fixed in grub2-2.04.0-19.mga8, but there are lots of other issues fixed upstream in 2.06 yet to be addressed.

Whiteboard: MGA7TOO => MGA8TOO, MGA7TOO

Apparently there's no 2.06 release yet.

Quoting the article in Comment 1:
"Given the difficulty of this kind of ecosystem-wide update/revocation, there is a strong desire to avoid having to do it again six months later. To that end, a large effort — spanning multiple security teams at Oracle, Red Hat, Canonical, VMware, and Debian — using static analysis tools and manual review helped identify and fix dozens of further vulnerabilities and dangerous operations throughout the codebase that do not yet have individual CVEs assigned."

So it sounds like we should pull all fixes from upstream git.

CC'ing tmb per Nicholas L's request.

Status comment: Fixed upstream in 2.06 => Fixed upstream in git
CC: (none) => tmb

cauldron:

CVE-2020-10713 is already fixed by patch 0225-yylex-Make-lexer-fatal-errors-actually-be-fatal.patch

CC: (none) => mageia

Cauldron: 

CVE-2020-14308 is already fixed by 0228-calloc-Use-calloc-at-most-places.patch

We've already addressed the CVEs in Cauldron, that's not the issue.  The issue was all of the other fixes upstream (see Comment 10) that didn't receive CVEs.

For Mageia 7, we'll live with just fixing the CVEs.

oh ok :-)

Upstream has posted a thread, with CVEs assigned, and 117 security patches identified:
https://www.mail-archive.com/grub-devel@gnu.org/msg31641.html

(In reply to David Walser from comment #15)
> Upstream has posted a thread, with CVEs assigned, and 117 security patches
> identified:
> https://www.mail-archive.com/grub-devel@gnu.org/msg31641.html

hm, quickly parsing that CVE list only CVE-2021-20225 and CVE-2021-20233 are "generic" ones that can "affect" us... 

as the rest are secure boot releated which we dont support anyway...

of course that dont mean we cant fix them ...

I wish they roll up a 2.06 soon

(In reply to Thomas Backlund from comment #16)
> hm, quickly parsing that CVE list only CVE-2021-20225 and CVE-2021-20233 are
> "generic" ones that can "affect" us... 
> 
> as the rest are secure boot releated which we dont support anyway...

Yes, that's a good point, and why I haven't generally been super stressed about this.

(In reply to Thomas Backlund from comment #17)
> I wish they roll up a 2.06 soon

I agree, and so do the people I got that link from.

RedHat has issued an advisory for this on March 2:
https://access.redhat.com/errata/RHSA-2021:0696

Debian has issued an advisory for this on March 2:
https://www.debian.org/security/2021/dsa-4867

GRUB 2.06~rc1 is out
https://lists.gnu.org/archive/html/grub-devel/2021-03/msg00219.html

Apparently you have to use some --disable-shim-lock option with the new version, though I don't know if it impacts us.  I saw some Linux security folks discussing it last week:
https://lists.gnu.org/archive/html/grub-devel/2021-03/msg00124.html

removing cauldron from targets

Version: Cauldron => 8
Whiteboard: MGA8TOO, MGA7TOO => MGA7TOO

Fedora has issued an advisory on March 26:
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/SPZHLZ3UEVV7HQ6ETAHB7NRBRTPLHCNF/

Summary: grub2 new security issues CVE-2020-10713, CVE-2020-1430[89], CVE-2020-1431[01], CVE-2020-1570[5-7] => grub2 new security issues CVE-2020-10713, CVE-2020-1430[89], CVE-2020-1431[01], CVE-2020-14372, CVE-2020-1570[5-7], CVE-2021-20225, CVE-2021-20233, CVE-2020-25632, CVE-2020-25647, CVE-2020-27749, CVE-2020-27779

openSUSE has issued an advisory for this on March 22:
https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/thread/XXPYL42MSKRB4D7LRFMW7PBGGLKSJKPS/

Ubuntu has issued an advisory for this on June 18:
https://ubuntu.com/security/notices/USN-4992-1

I'd say that grub-2.06 has been quite tested in cauldron so I guess I can backport it to mga8?
And maybe backport grub-2.04 to mga7?

Sounds good.

(In reply to Thomas Backlund from comment #16)
> as the rest are secure boot releated which we dont support anyway...

We could try to support SecureBoot in mga9 like other distros are doing.

Anway grub2-2.06-1.1.mga8 is there for mga8

Source RPM: grub2-2.04.0-18.mga8.src.rpm => grub2-2.06-1.1.mga8

Mageia 7 build failed due to missing efi-srpm-macros.

Mageia 8 packages (mistakenly built with subrel):
grub2-2.06-1.1.mga8
grub2-efi-2.06-1.1.mga8
grub2-common-2.06-1.1.mga8
grub2-emu-2.06-1.1.mga8
grub2-mageia-theme-2.06-1.1.mga8
grub2-emu-modules-2.06-1.1.mga8

from grub2-2.06-1.1.mga8.src.rpm

Thierry successfully built it on Mageia 7:
grub2-2.04.0-1.1.mga7
grub2-efi-2.04.0-1.1.mga7
grub2-common-2.04.0-1.1.mga7
grub2-mageia-theme-2.04.0-1.1.mga7
grub2-emu-2.04.0-1.1.mga7
grub2-emu-modules-2.04.0-1.1.mga7

from grub2-2.04.0-1.1.mga7.src.rpm


We'll need to identify which CVEs we're fixing in each of these updates.

But for armv7 but we don't care for mga7.
I guess a bug clone is in order for grub2-2.04.0-1.1.mga7.src.rpm

as mga7 support ends in some days, i don't know if we really want it to be fixed in mga7

(In reply to Nicolas Lécureuil from comment #33)
> as mga7 support ends in some days, i don't know if we really want it to be
> fixed in mga7

Packages are here in core/updates testing. This can be pushed ASAP as tests are done.

CC: (none) => ouaurelien

Nicolas, it's built, there's no reason we can't fix it.  They can both be handled in this bug.

I would clone this bug in order to have this one for mga8 & another one for mga7 for consistency but I'll leave that to you

We can have two different advisories in the same bug, we just need to know which CVEs each update is fixing.

Still need a list of CVEs fixed by each update, but assigning to QA so it can be tested.

Assignee: pkg-bugs => qa-bugs
Status comment: Fixed upstream in git => (none)

Tested both mga7 and mga8 grub2 on  64-bit Plasma systems on the same MBR hardware. No installation issues on either system.

The mga8 grub2 menu looks fine, and boots to a working desktop. It is OK for MBR systems. Still needs a test with efi hardware.

The mga7 menu is a different story. The text color has been changed to be much darker, so dark that unhighlighted text is nearly invisible on the mga7 background. The menu does work OK, and highlighted text is very visible, so the problem is only cosmetic. However, users will NOT be happy with it.

CC: (none) => andrewsfarm

Oups theming was synced with mga8…

Tested with QA repo on MGA 8 XFCE 64.

Grub2 menu looks fine, and boots to a working desktop. It is OK for MBR systems too.

CC: (none) => guillaume.royer

Before testing on an efi system,
what means mistakenly built with subrel (Comment#30)?
Should we wait for a new batch of binaries?

Ulrich

CC: (none) => bequimao.de

(In reply to Ulrich Beckmann from comment #42)
> Before testing on an efi system,
> what means mistakenly built with subrel (Comment#30)?
> Should we wait for a new batch of binaries?
> 
> Ulrich

No, there will not any new packages. In facts, when a package is updated Tina newer version, we usually made a new package with a reinitialized mkrel equal to 1.

Subrel are for fixed version package with only new patches to fix CVE or a specific bugfix from an upstream version.

(In reply to Aurelien Oudelet from comment #43)
> No, there will not any new packages. 

Does this mean that the M7 issue discussed in Comment 39 and Comment 40 will not be corrected? Of course I can be overruled, but you should be aware that in good conscience I cannot give an OK for M7 if it isn't.

(In reply to Thomas Andrews from comment #44)
> (In reply to Aurelien Oudelet from comment #43)
> > No, there will not any new packages. 
> 
> Does this mean that the M7 issue discussed in Comment 39 and Comment 40 will
> not be corrected? Of course I can be overruled, but you should be aware that
> in good conscience I cannot give an OK for M7 if it isn't.

I talked about the mga8 package which has a subrel (1.1) instead of a mkrel of 1.
I don't know about plans from packager.

The subrel mistake was a note to Thierry to remember to not make that mistake again in the future.

If QA rejects the Mageia 7 update, we'll just have to cancel it, so remove it from the whiteboard if that's the case.

(In reply to Thomas Andrews from co

mment #44)
> (In reply to Aurelien Oudelet from comment #43)
> > No, there will not any new packages. 
> 
> Does this mean that the M7 issue discussed in Comment 39 and Comment 40 will
> not be corrected? Of course I can be overruled, but you should be aware that
> in good conscience I cannot give an OK for M7 if it isn't.

if you edit:

/boot/grub2/themes/maggy/theme.txt

and change item_color line to say:

 item_color = "#25adf1"


does it look ok then ?

MGA7-64 Plasma on Lenovo B50
No installation issues.
Installed updates as per Comment 31 and confirm problem as in Comment 39, but the suggestion in Comment 47 cures it.
I cann't decide whether this update is good to go if such intervention after installation is needed

CC: (none) => herman.viaene

Removed mga7 from the whiteboard. Manual intervention such as in comment 47
is not ok on an update for such a high visibility package.

Validating the update for mga8 based on my testing and the other tests above.

CC: (none) => davidwhodgins, sysadmin-bugs
Keywords: (none) => validated_update
Whiteboard: MGA7TOO => MGA8-64-OK

Suggested Advisory:
========================

Updated grub2 packages fix security vulnerabilities:

All CVEs below are against the SecureBoot GRUB2 functionality.
We do not ship this as part of Mageia. Therefore, we ship an updated grub2
package to 2.06 for Mageia 8 fixing upstream bugfixes.

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-10713).

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-14308).

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-14309).

There is an issue on grub2 before version 2.06 at function read_section_as_string().
It expects a font name to be at max UINT32_MAX - 1 length in bytes but it
doesn't verify it before proceed with buffer allocation to read the value from
the font value. An attacker may leverage that by crafting a malicious font file
which has a name with UINT32_MAX, leading to read_section_as_string() to an
arithmetic overflow, zero-sized allocation and further heap-based buffer overflow
(CVE-2020-14310).

There is an issue with grub2 before version 2.06 while handling symlink on ext
filesystems. A filesystem containing a symbolic link with an inode size of
UINT32_MAX causes an arithmetic overflow leading to a zero-sized memory
allocation with subsequent heap-based buffer overflow (CVE-2020-14311).

A flaw was found in grub2 in versions prior to 2.06, where it incorrectly
enables the usage of the ACPI command when Secure Boot is enabled. This flaw 
allows an attacker with privileged access to craft a Secondary System Description
Table (SSDT) containing code to overwrite the Linux kernel lockdown variable
content directly into memory. The table is further loaded and executed by the
kernel, defeating its Secure Boot lockdown and allowing the attacker to load
unsigned code. The highest threat from this vulnerability is to data
confidentiality and integrity, as well as system availability (CVE-2020-14372).

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 versions (CVE-2020-15705).

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 (CVE-2020-15706).

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 (CVE-2020-15707).

A flaw was found in grub2 in versions prior to 2.06. The option parser allows an
attacker to write past the end of a heap-allocated buffer by calling certain
commands with a large number of specific short forms of options. The highest
threat from this vulnerability is to data confidentiality and integrity as well
as system availability (CVE-2021-20225).

A flaw was found in grub2 in versions prior to 2.06. Setparam_prefix() in the
menu rendering code performs a length calculation on the assumption that
expressing a quoted single quote will require 3 characters, while it actuall
requires 4 characters which allows an attacker to corrupt memory by one byte for
each quote in the input. The highest threat from this vulnerability is to data
confidentiality and integrity as well as system availability (CVE-2021-20233).

A flaw was found in grub2 in versions prior to 2.06. The rmmod implementation
allows the unloading of a module used as a dependency without checking if any
other dependent module is still loaded leading to a use-after-free scenario.
This could allow arbitrary code to be executed or a bypass of SecureBoot
protections. The highest threat from this vulnerability is to data
confidentiality and integrity as well as system availability (CVE-2020-25632).

A flaw was found in grub2 in versions prior to 2.06. During USB device
initialization, descriptors are read with very little bounds checking and assumes
the USB device is providing sane values. If properly exploited, an attacker
could trigger memory corruption leading to arbitrary code execution allowing a
bypass of the Secure Boot mechanism. The highest threat from this vulnerability
is to data confidentiality and integrity as well as system availability
(CVE-2020-25647).

A flaw was found in grub2 in versions prior to 2.06. Variable names present are
expanded in the supplied command line into their corresponding variable contents
using a 1kB stack buffer for temporary storage, without sufficient bounds
checking. If the function is called with a command line that references a
variable with a sufficiently large payload, it is possible to overflow the stack
buffer, corrupt the stack frame and control execution which could also circumvent
Secure Boot protections. The highest threat from this vulnerability is to data
confidentiality and integrity as well as system availability (CVE-2020-27749).

A flaw was found in grub2 in versions prior to 2.06. The cutmem command does not
honor secure boot locking allowing an privileged attacker to remove address
ranges from memory creating an opportunity to circumvent SecureBoot protections
after proper triage about grub's memory layout. The highest threat from this
vulnerability is to data confidentiality and integrity as well as system
availability (CVE-2020-27779).

References:
 - https://bugs.mageia.org/show_bug.cgi?id=27018
 - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10713
 - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14308
 - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14309
 - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14310
 - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14311
 - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14372
 - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15705
 - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15706
 - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15707
 - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-20225
 - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-20233
 - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25632
 - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25647
 - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-27749
 - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-27779
 - https://lists.gnu.org/archive/html/grub-devel/2021-03/msg00007.html
 - https://lists.gnu.org/archive/html/grub-devel/2021-06/msg00022.html
 - https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/SPZHLZ3UEVV7HQ6ETAHB7NRBRTPLHCNF/
 - https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/thread/XXPYL42MSKRB4D7LRFMW7PBGGLKSJKPS/
 - https://ubuntu.com/security/notices/USN-4992-1
========================

Updated packages in core/updates_testing:
========================
grub2-2.06-1.1.mga8
grub2-common-2.06-1.1.mga8
grub2-efi-2.06-1.1.mga8
grub2-emu-2.06-1.1.mga8
grub2-emu-modules-2.06-1.1.mga8
grub2-mageia-theme-2.06-1.1.mga8

from SRPM:
grub2-2.06-1.1.mga8.src.rpm

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2021-0315.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED