[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [SECURITY PATCH 00/28] Multiple GRUB2 vulnerabilities - BootHole
From: |
Dimitri John Ledkov |
Subject: |
Re: [SECURITY PATCH 00/28] Multiple GRUB2 vulnerabilities - BootHole |
Date: |
Wed, 29 Jul 2020 22:20:01 +0100 |
On Wed, 29 Jul 2020 at 21:20, John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
>
> On 7/29/20 10:12 PM, Christian Hesse wrote:
> > This does not apply on top of grub 2.04. Will downstream maintainers have to
> > do their cherry-picking on its own or will a maintenance branch on top of
> > grub-2.04 (or what ever) be available?
> > I would like to push updates to the Arch Linux repositories.
>
> You may want to look at the Debian package which already has the patches
> applied in Debian unstable [1].
>
> I'm surprised that Arch did not receive a disclosure of the vulnerabilities
> under NDA since Debian and the various enterprise distributions have it
> already.
Disclosures were done to a subset of binary distributions that have a
trust path to shims signed with Microsoft UEFI CA 2011 db key. Arch
Linux does not provide shim-signed with keys controlled by Arch Linux
and it doesn't provide pre-signed secureboot kernels.
Reading Arch Linux documentation it seems that Fedora's shim is used
together with self-signed Mok Keys.
Mitigation strategy for Arch Linux will then be quite different to
everyone else:
1) Update to new shim from fedora when available, as previous ones are
going to be revoked by the dbxupdate from uefi.org
2) Patch Archlinux grub
3) Patch Archilinux kernel for lockdown bypass
4) Generate new MOK key, enroll it into MOK
5) Sign patched grub/kernel with the new MOK key
6) Provide instructions for users to revoke their old key via MOKX,
i.e. use mokutil --mokx --import existing cert; or for example delete
the old key from MOK with --delete old-cert.der
This is just a rough guideline, please analyze how signing keys are
controlled and used on typical Arch Linux deployment and adjust things
to taste.
The key point is to rotate the signing key used for
shim/grub/kernel/fwupd, only use the new key to sign fixed things, and
ensure that old key is no longer trusted (removed from MOK, or added
to MOKX).
--
Regards,
Dimitri.
- [SECURITY PATCH 26/28] efi: Fix use-after-free in halt/reboot path, (continued)
- [SECURITY PATCH 26/28] efi: Fix use-after-free in halt/reboot path, Daniel Kiper, 2020/07/29
- [SECURITY PATCH 27/28] loader/linux: Avoid overflow on initrd size calculation, Daniel Kiper, 2020/07/29
- [SECURITY PATCH 28/28] linux: Fix integer overflows in initrd size handling, Daniel Kiper, 2020/07/29
- [SECURITY PATCH 09/28] xnu: Fix double free in grub_xnu_devprop_add_property(), Daniel Kiper, 2020/07/29
- [SECURITY PATCH 16/28] relocator: Protect grub_relocator_alloc_chunk_addr() input args against integer underflow/overflow, Daniel Kiper, 2020/07/29
- [SECURITY PATCH 17/28] relocator: Protect grub_relocator_alloc_chunk_align() max_addr against integer underflow, Daniel Kiper, 2020/07/29
- [SECURITY PATCH 20/28] relocator: Fix grub_relocator_alloc_chunk_align() top memory allocation, Daniel Kiper, 2020/07/29
- [SECURITY PATCH 21/28] hfsplus: Fix two more overflows, Daniel Kiper, 2020/07/29
- Re: [SECURITY PATCH 00/28] Multiple GRUB2 vulnerabilities - BootHole, Christian Hesse, 2020/07/29