Page MenuHomePureOS Tracker

GRUB security issues from the 18 February (mostly secure boot bypass)
Open, Needs TriagePublic

Description

Hi,

The GRUB shipped in byzantium should be affected by some security issues as it's at the 2.06 revision and doesn't have the latest security patches.

I'm notifying PureOS of the issue as not everyone follow the GRUB mailing list and GRUB doesn't plan to make a new release soon (more details below).

However I'm unsure how important is UEFI secure boot and/or GRUB for PureOS:

  • You do have UEFI secure boot (In the past I tested pureos-10~devel-gnome-live-20220602_amd64.iso and pureos-10~devel-plasma-live-20220602_amd64.iso installers on a Thinkpad X230 with UEFI secure boot on, and both booted) and in byzantium you also have shim-signed from Debian that is signed by Microsoft. But I'm unsure if it's just because PureOS is based on Debian or if you really want to support UEFI secure boot. Also note that If I need to do tests I don't have this laptop anymore (it was not mine), but I might be able to borrow another one to test UEFI secure boot.
  • You also have Pure Boot available on some of the computers shipped with PureOS, so maybe UEFI secure boot is not very important, and as I understand Pure Boot doesn't depend on GRUB.

More details are available in the "[SECURITY PATCH 00/73] GRUB2 vulnerabilities - 2025/02/18" thread From Daniel Kiper (Tuesday, 18 February 2025, archived online at https://lists.gnu.org/archive/html/grub-devel/2025-02/msg00024.html).

They list the following CVEs: CVE-2025-0690, CVE-2025-0622, CVE-2024-45775, CVE-2024-45777, CVE-2024-45778, CVE-2024-45779, CVE-2024-45781, CVE-2024-45782, CVE-2024-45783, CVE-2025-0624, CVE-2025-0677, CVE-2025-0684, CVE-2025-0685, CVE-2025-0686, CVE-2025-0689, CVE-2025-1125.

My understanding is that beside execution of code through a boot JPEG picture and through crafted filesystems (Linux is also not confident of its filesystem code, so it's probably not a big additional security risk), it only affects secure boot.

So not fixing these bugs might also be a valid option.

Trisquel for instance opted for that option as most FSDG compliant distributions don't support UEFI secure boot anyway and fixing this bug is complicated because GRUB didn't make a new release due to the lack of time (See Re: [SECURITY PATCH 00/73] GRUB2 vulnerabilities - 2025/02/18 From Christian Hesse (Fri, 21 Feb 2025 11:06:54 +0100), available at https://lists.gnu.org/archive/html/grub-devel/2025-02/msg00124.html for more details). Parabola also is not OK with updating GRUB to a non-release but it's not against adding additional grub-git packages. Libreboot, Canoeboot, and later on GNU Boot all fixed the issue as they all reuse GRUB to provide various secure boot schemes (users are supposed to write a custom grub.cfg for that).

If you want to fix it you would then need to:

  • Either apply the patches from Debian, reuse the newer Debian grub package, or build from git (more complicated due to the requirement to bootstrap gnulib when building from git).
  • Validate that the GRUB new revision. Arch Linux for instance had some difficulties with that and reverted to the GRUB release.

Event Timeline

GNUtoo created this task.Mon, Mar 24, 13:51