gnuboot @ Savannah: New GNU Boot 0.1 RC6 release.

This release is meant to fix multiple security issues that are present

in the GRUB version we use (2.06+).

Users having replaced the GNU Boot picture / logo with untrusted

pictures could have been affected if the pictures they used were

specially crafted to exploit a vulnerability in GRUB and take full

control of the computer. In general it's a good idea to avoid using

untrusted pictures in GRUB or other boot software to limit such risks

because software can have bugs (a similar issue also happened in a

free software UEFI implementation).

Users having implemented various user-respecting flavor(s) of

secure-boot, either by using GPG signatures and/or by using a GRUB

password combined with full disk encryption are also affected as these

security vulnerabilities could enable people to bypass secure-boot

schemes.

In addition there are also security vulnerabilities in file systems,

which also enable execution of code. When booting, GRUB has to load

files (like the Linux or linux-libre kernel) that are executed

anyway. But in some cases, it could still affect users.

This could happen when trying to boot from an USB key, and also having

another USB key that has a file system that was crafted to take

control of the computer.

At the time, no known exploits are known by the GNU Boot maintainers.

Why it took so long.

--------------------

The 18 February, the GRUB maintainer posted some patches on the

grub-devel mailing list in order to notify people that there were some

security vulnerabilities in GRUB that were fixed, and which commit

fixed them.

One of the GNU Boot maintainers saw these patches but didn't read the

mails and assumed that a new GRUB release was near and decided to wait

for it as this would make things easier as GRUB releases are tested in

many different situations.

However the thread posting these patches also mentioned that a new

release would take too much time and that the GRUB contributors and/or

maintainers already had a lot to deal with.

It took a while to realize the issue: a second GNU Boot maintainer saw

the GRUB security vulnerabilities later on, and at this point they

realized that nothing had happened yet on GRUB side yet and they

looked into the issue.

In addition the computer of one of the GNU Boot maintainer broke,

which also delayed the review of the GNU Boot patches meant to fix

this security issues.

These patches also contain fixes for the GNU Boot build system as well

to ensure users building GNU Boot themselves really do get an updated

GRUB version.

As this is a new release candidate, we also need help for reporting on

which computers and/or configuration it works or doesn't work,

especially because we had to update to an unreleased GRUB version to

get the fixes (see below for more details).

Other affected distributions?

-----------------------------

We started telling the Canoeboot and Libreboot maintainer about the

issue to later find out that the issue was fixed since the 18

February, and their users were also notified via a news, so everything

is good on that side.

For most 100% free distributions, using GRUB from git would be

a significant effort in testing and/or in packaging.

We notified Trisquel, Parabola and Guix and the ones who responded are

not comfortable with updating GRUB to a not-yet released git

revision. Though in the case of Parabola nothing prevent adding a new

grub-git package that has no known vulnerabilities in addition to the

existing grub package, so patches for that are welcome.

As for the other distributions, most of them do support secure boot

(by supporting UEFI secure boot), but they are probably aware of the

issue as (maintainers of) distributions like Debian or Arch Linux

either responded to the thread on the GRUB mailing list, or were

mentioned as having fixed the issue in that thread.

At the time of writing, the affected GRUBs versions seems not to be

blacklisted yet by UEFIs, so it also leaves some time to fix the

issue, and things like GRUB password can usually be bypassed easily

unless people use distributions like GNU Boot or Canoeboot and

configure both the hardware and the software to support a secure boot

scheme that respect users freedoms.

As for PureOS we just notified them in a bug report as they have UEFI

secure boot, but in another hand we don't know if they are aware of

that (they are based on Debian so it could be inherited from Debian

and not something supported/advertised), and because Purism (the

company behind PureOS) ships computers with their own secure boot

scheme (PureBoot), since it works in a very different way we are not

sure if people could be affected or not.

References and details

----------------------

This release should fix the following CVEs affecting previous GRUB

2.06: 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.

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

Source: Planet GNU