grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [SECURITY PATCH 00/13] Multiple GRUB2 vulnerabilities - 2022/11/15


From: Daniel Kiper
Subject: Re: [SECURITY PATCH 00/13] Multiple GRUB2 vulnerabilities - 2022/11/15
Date: Tue, 15 Nov 2022 19:16:41 +0100

On Tue, Nov 15, 2022 at 07:00:20PM +0100, Daniel Kiper wrote:
> Hi all,
>
> This patch set contains a bundle of fixes for various security flaws 
> discovered
> in the GRUB2 font code during last few months. The most severe ones, i.e. 
> potentially
> exploitable, have CVEs assigned and are listed at the end of this email.
>
> Details of exactly what needs updating will be provided by the respective
> distros and vendors when updates become available. Here [1] we are listing at
> least some links to the messaging known at the time of this posting.
>
> Full mitigation against all CVEs will require updated shim with latest SBAT
> (Secure Boot Advanced Targeting) [2] data provided by distros and vendors.
> This time UEFI revocation list (dbx) will not be used and revocation of broken
> artifacts will be done with SBAT only. For information on how to apply the
> latest SBAT revocations, please see mokutil(1). Vendor shims may explicitly
> permit known older boot artifacts to boot.
>
> Updated GRUB2, shim and other boot artifacts from all the affected vendors 
> will
> be made available when the embargo lifts or some time thereafter.
>
> I am posting all the GRUB2 upstream patches which fix all security bugs found
> and reported up until now. Major Linux distros carry or will carry soon one
> form or another of these patches. Now all the GRUB2 upstream patches are in
> the GRUB2 git repository [3] too.
>
> I would like to thank, in alphabetical order, the following people who were 
> working
> really hard on the GRUB, shim and other things related to these issues:
>   - Alexander Burmashev (Oracle),
>   - Chris Coulson (Canonical),
>   - D. Jared Dominguez (Red Hat),
>   - Daniel Axtens,
>   - Eric Snowberg (Oracle),
>   - Ilya Okomin (Oracle),
>   - Jan Setje-Eilers (Oracle),
>   - Julian Andres Klode (Canonical),
>   - Marco A Benatto (Red Hat),
>   - Marta Lewandowska (Red Hat),
>   - Peter Jones (Red Hat),
>   - Robbie Harwood (Red Hat),
>   - Steve McIntyre (Debian),
>   - Zhang Boyang.
>
> We would not be able to succeed without all your hard work.
>
> It was very big pleasure to work with you all.
>
> Thank you!
>
> Daniel
>
> [1] Red Hat: https://access.redhat.com/security/security-updates/#/
>
> [2] https://github.com/rhboot/shim/blob/main/SBAT.md
>
> [3] https://git.savannah.gnu.org/gitweb/?p=grub.git
>     https://git.savannah.gnu.org/git/grub.git
>
> *******************************************************************************
>
> CVE-2022-2601 grub2: A buffer overflow in grub_font_construct_glyph() can 
> lead to out-of-bound write and possible secure boot by-pass
> 6.4/CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H
>
> A buffer overflow was found in grub_font_construct_glyph(). A malicious 
> crafted
> pf2 font can lead to an overflow when calculating the max_glyph_size value,
> allocating a smaller than needed buffer for the glyph, this further leads to
> a buffer overflow and a heap based out-of-bounds write. An attacker may use 
> this
> vulnerability to circumvent the secure boot mechanism.
>
> Reported-by: Zhang Boyang
>
> *******************************************************************************
>
> CVE-2022-3775 grub2: Heap based out-of-bounds write when redering certain 
> unicode sequences
> 6.3/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H
>
> When rendering certain unicode sequences, GRUB2's font code doesn't properly
> validate if the informed glyph's width and height is constrained within bitmap
> size. As consequence an attacker can craft an input which will lead to
> a out-of-bounds write into GRUB2's heap, leading to memory corruption and
> availability issues. Although complex, arbitrary code execution could not
> be discarded.
>
> Reported-by: Zhang Boyang

Ugh! Zhang told me credit goes to Daniel Axtens here. Sorry for this
mistake...

Daniel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]