Re: [SECURITY PATCH 000/117] Multiple GRUB2 vulnerabilities - 2021/03/02 round

2021-03-22 Thread Daniel Kiper
On Thu, Mar 18, 2021 at 09:58:23AM +0100, Paul Menzel wrote:
> Dear Darren, dear Darren,
>
> Am 02.03.21 um 19:00 schrieb Daniel Kiper:
>
> Thank you very much for finding and fixing all these issues, and
> coordinating the publication.
>
> […]
>
> >   .../lib/gnulib-patches/fix-null-state-deref.patch  |  12 +
> >   .../gnulib-patches/fix-regcomp-uninit-token.patch  |  15 +
> >   .../gnulib-patches/fix-regexec-null-deref.patch|  12 +
> >   .../lib/gnulib-patches/fix-uninit-structure.patch  |  11 +
> >   .../lib/gnulib-patches/fix-unused-value.patch  |  14 +
> Just a small question, if all these fixes were sent and applied upstream.

I am going to send all of these fixes upstream and bump the gnulib
version when they are applied or the issues are fixed in the other way.
Though after release. However, if you want to do it earlier go ahead.
Just keep me in the loop...

Daniel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel


Re: [SECURITY PATCH 000/117] Multiple GRUB2 vulnerabilities - 2021/03/02 round

2021-03-18 Thread Paul Menzel

Dear Darren, dear Darren,


Am 02.03.21 um 19:00 schrieb Daniel Kiper:

Thank you very much for finding and fixing all these issues, and 
coordinating the publication.


[…]


  .../lib/gnulib-patches/fix-null-state-deref.patch  |  12 +
  .../gnulib-patches/fix-regcomp-uninit-token.patch  |  15 +
  .../gnulib-patches/fix-regexec-null-deref.patch|  12 +
  .../lib/gnulib-patches/fix-uninit-structure.patch  |  11 +
  .../lib/gnulib-patches/fix-unused-value.patch  |  14 +

Just a small question, if all these fixes were sent and applied upstream.


Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel


Re: [SECURITY PATCH 000/117] Multiple GRUB2 vulnerabilities - 2021/03/02 round

2021-03-09 Thread Daniel Kiper
On Tue, Mar 09, 2021 at 10:57:36AM -0500, Neal Gompa wrote:
> On Tue, Mar 2, 2021 at 4:08 PM Daniel Kiper  wrote:
> >
> > Hi Adrian,
> >
> > On Tue, Mar 02, 2021 at 08:37:14PM +0100, John Paul Adrian Glaubitz wrote:
> > > Hi Daniel!
> > >
> > > On 3/2/21 7:00 PM, Daniel Kiper wrote:
> > > > The BootHole vulnerability [1][2] announced last year encouraged many 
> > > > people to
> > > > take a closer look at the security of boot process in general and the 
> > > > GRUB
> > > > bootloader in particular. Due to that, during past few months we were 
> > > > getting
> > > > reports of, and also discovering various security flaws in the GRUB 
> > > > ourselves.
> > > > You can find the list of most severe ones which got CVEs assigned at 
> > > > the end of
> > > > this message. The patch bundle fixing all these issues in the upstream 
> > > > GRUB
> > > > contains 117 patches.
> > >
> > > Huge thanks and kudos to everyone involved fixing all these 
> > > vulnerabilities!
> > >
> > > Given the amount of patches, wouldn't it make sense to push an RC 
> > > candidate
> > > for 2.06 in the near future so that distributions can start shipping the 
> > > pre-
> > > release and avoiding to carry this large amount of patches?
> >
> > I am planning to cut 2.06-rc1 in matter of days...
> >
>
> Any status update on this? The delta between 2.04 and HEAD is huge,
> and I'd rather have a release to work from now...

WIP, expect rc1 by the end of this week...

> 真実はいつも一つ!/ Always, there's only one truth!

Hmmm... Interesting... :-)

Daniel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel


Re: [SECURITY PATCH 000/117] Multiple GRUB2 vulnerabilities - 2021/03/02 round

2021-03-09 Thread Neal Gompa
On Tue, Mar 2, 2021 at 4:08 PM Daniel Kiper  wrote:
>
> Hi Adrian,
>
> On Tue, Mar 02, 2021 at 08:37:14PM +0100, John Paul Adrian Glaubitz wrote:
> > Hi Daniel!
> >
> > On 3/2/21 7:00 PM, Daniel Kiper wrote:
> > > The BootHole vulnerability [1][2] announced last year encouraged many 
> > > people to
> > > take a closer look at the security of boot process in general and the GRUB
> > > bootloader in particular. Due to that, during past few months we were 
> > > getting
> > > reports of, and also discovering various security flaws in the GRUB 
> > > ourselves.
> > > You can find the list of most severe ones which got CVEs assigned at the 
> > > end of
> > > this message. The patch bundle fixing all these issues in the upstream 
> > > GRUB
> > > contains 117 patches.
> >
> > Huge thanks and kudos to everyone involved fixing all these vulnerabilities!
> >
> > Given the amount of patches, wouldn't it make sense to push an RC candidate
> > for 2.06 in the near future so that distributions can start shipping the 
> > pre-
> > release and avoiding to carry this large amount of patches?
>
> I am planning to cut 2.06-rc1 in matter of days...
>

Any status update on this? The delta between 2.04 and HEAD is huge,
and I'd rather have a release to work from now...


-- 
真実はいつも一つ!/ Always, there's only one truth!

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel


Re: [SECURITY PATCH 000/117] Multiple GRUB2 vulnerabilities - 2021/03/02 round

2021-03-02 Thread Daniel Kiper
Hi Adrian,

On Tue, Mar 02, 2021 at 08:37:14PM +0100, John Paul Adrian Glaubitz wrote:
> Hi Daniel!
>
> On 3/2/21 7:00 PM, Daniel Kiper wrote:
> > The BootHole vulnerability [1][2] announced last year encouraged many 
> > people to
> > take a closer look at the security of boot process in general and the GRUB
> > bootloader in particular. Due to that, during past few months we were 
> > getting
> > reports of, and also discovering various security flaws in the GRUB 
> > ourselves.
> > You can find the list of most severe ones which got CVEs assigned at the 
> > end of
> > this message. The patch bundle fixing all these issues in the upstream GRUB
> > contains 117 patches.
>
> Huge thanks and kudos to everyone involved fixing all these vulnerabilities!
>
> Given the amount of patches, wouldn't it make sense to push an RC candidate
> for 2.06 in the near future so that distributions can start shipping the pre-
> release and avoiding to carry this large amount of patches?

I am planning to cut 2.06-rc1 in matter of days...

Daniel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel


Re: [SECURITY PATCH 000/117] Multiple GRUB2 vulnerabilities - 2021/03/02 round

2021-03-02 Thread Bruce Dubbs

On 3/2/21 1:37 PM, John Paul Adrian Glaubitz wrote:

Hi Daniel!

On 3/2/21 7:00 PM, Daniel Kiper wrote:

The BootHole vulnerability [1][2] announced last year encouraged many people to
take a closer look at the security of boot process in general and the GRUB
bootloader in particular. Due to that, during past few months we were getting
reports of, and also discovering various security flaws in the GRUB ourselves.
You can find the list of most severe ones which got CVEs assigned at the end of
this message. The patch bundle fixing all these issues in the upstream GRUB
contains 117 patches.


Huge thanks and kudos to everyone involved fixing all these vulnerabilities!

Given the amount of patches, wouldn't it make sense to push an RC candidate
for 2.06 in the near future so that distributions can start shipping the pre-
release and avoiding to carry this large amount of patches?


It makes sense to not rely on distros to do the job of GRUB.  It's time 
to get on a release schedule and stick to it.  Very complex packages 
like gcc, glibc, and binutils are on a six month schedule.  Why not GRUB?


From https://ftp.gnu.org/gnu/grub/:
grub-1.99.tar.gz2011-05-14
grub-2.00.tar.gz2012-06-27
grub-2.02.tar.gz2017-04-26
grub-2.04.tar.gz2019-07-05
grub-2.06.tar.gz202?-??-??

If you are waiting for perfection, you will never get there.

  -- Bruce

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel


Re: [SECURITY PATCH 000/117] Multiple GRUB2 vulnerabilities - 2021/03/02 round

2021-03-02 Thread John Paul Adrian Glaubitz
Hi Daniel!

On 3/2/21 7:00 PM, Daniel Kiper wrote:
> The BootHole vulnerability [1][2] announced last year encouraged many people 
> to
> take a closer look at the security of boot process in general and the GRUB
> bootloader in particular. Due to that, during past few months we were getting
> reports of, and also discovering various security flaws in the GRUB ourselves.
> You can find the list of most severe ones which got CVEs assigned at the end 
> of
> this message. The patch bundle fixing all these issues in the upstream GRUB
> contains 117 patches.

Huge thanks and kudos to everyone involved fixing all these vulnerabilities!

Given the amount of patches, wouldn't it make sense to push an RC candidate
for 2.06 in the near future so that distributions can start shipping the pre-
release and avoiding to carry this large amount of patches?

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel


[SECURITY PATCH 000/117] Multiple GRUB2 vulnerabilities - 2021/03/02 round

2021-03-02 Thread Daniel Kiper
Hi all,

The BootHole vulnerability [1][2] announced last year encouraged many people to
take a closer look at the security of boot process in general and the GRUB
bootloader in particular. Due to that, during past few months we were getting
reports of, and also discovering various security flaws in the GRUB ourselves.
You can find the list of most severe ones which got CVEs assigned at the end of
this message. The patch bundle fixing all these issues in the upstream GRUB
contains 117 patches.

In addition, we have been working on a generation number based revocation
scheme termed UEFI Secure Boot Advanced Targeting (SBAT) [3]. This will require
an UEFI dbx release and resigning all the artifacts -- shim, GRUB, kernel,
etc. -- needed to boot the system. This is the same as we did for the BootHole
series of vulnerabilities, but the SBAT work is designed to make this process
much less painful in the future.

Details of exactly what needs updating will be provided by the respective
distros and vendors when updates become available. Here [4] we are listing at
least some links to the messaging known at the time of this posting.

It is important to know that shim and SBAT development is still ongoing.

Full mitigation against all the CVEs will require an updated UEFI revocation
list (dbx) which, in at least some cases, will not allow Secure Boot with
today's boot artifacts. Vendor shims may explicitly permit known older boot
artifacts to boot. At some stage, the dbx on new hardware will be updated.

Updated GRUB2, shim and other boot artifacts from all the affected vendors will
be made available when the embargo lifts or some time thereafter. An updated
dbx from the various affected vendors will also ship, although possibly not at
the same time. The new Microsoft dbx will be provided for download here [5].

I am posting all the GRUB2 upstream patches which fixes 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 [6] too.

In particular 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 Co (Microsoft),
  - Chris Coulson (Canonical),
  - Cliff Perry (Red Hat),
  - Colin Watson (Debian),
  - D. Jared Dominguez (Red Hat),
  - Daniel Axtens (IBM),
  - Darren Kenny (Oracle),
  - Dimitri John Ledkov (Canonical),
  - Eric Snowberg (Oracle),
  - Ilja Van Sprundel (IOActive),
  - Ilya Okomin (Oracle),
  - Jan Setje-Eilers (Oracle),
  - Javier Martinez Canillas (Red Hat),
  - Jeremiah Cox (Microsoft),
  - John Haxby (Oracle),
  - Jordan Geurten (Microsoft),
  - Joseph Tartaro (IOActive),
  - Julian Andres Klode (Canonical),
  - Marco A Benatto (Red Hat),
  - Mario Limonciello (Dell),
  - Mathieu Trudel-Lapierre (Stack8),
  - Matthew Garrett (Google),
  - Máté Kukri,
  - Noam Rathaus (SSD Secure Disclosure),
  - NyankoSec (SSD Secure Disclosure),
  - Paulo Flabiano Smorigo (Canonical),
  - Peter Jones (Red Hat),
  - Richard Hughes (Red Hat),
  - Sarah Jacobus (Microsoft),
  - Steve McIntyre (Debian),
  - Teddy Reed,
  - Thomas Frauendorfer (Miray Software),
  - Ulrich Bauer (Miray Software),
  - Yves-Alexis Perez (Debian).

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] https://lists.gnu.org/archive/html/grub-devel/2020-07/msg00034.html

[2] https://www.eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/

[3] https://github.com/rhboot/shim/blob/main/SBAT.md

[4] Canonical: 
https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/GRUB2SecureBootBypass2021
Debian:https://www.debian.org/security/2021-GRUB-UEFI-SecureBoot
Red Hat:   https://access.redhat.com/security/vulnerabilities/RHSB-2021-003
SUSE:  https://www.suse.com/support/kb/doc/?id=19892

[5] https://uefi.org/revocationlistfile

[6] https://git.savannah.gnu.org/gitweb/?p=grub.git=view+git+repository
https://git.savannah.gnu.org/git/grub.git

***

CVE-2020-14372 grub2: The acpi command allows privileged user to load crafted
   ACPI tables when Secure Boot is enabled
CWE-184
7.5/CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H

GRUB2 enables the use of the command acpi even when Secure Boot is signaled by
the firmware. An attacker with local root privileges to can drop a small SSDT
in /boot/efi and modify grub.cfg to instruct grub to load said SSDT. The SSDT
then gets run by the kernel and it overwrites the kernel lock down configuration
enabling the attacker to load unsigned kernel modules and kexec unsigned code.

Reported-by: Máté Kukri

***

CVE-2020-25632 grub2: Use-after-free in rmmod command
CWE-416