It is currently unclear what exactly is causing this issue. Waiting for details from Red Hat and upstream.

perhaps its a world readable file on fedora there.

Details (oss posting from Maxim Suhanov)

References:

https://dfir.ru/2024/01/15/cve-2023-4001-a-vulnerability-in-the-downstream-grub-boot-manager/
https://access.redhat.com/security/cve/cve-2023-4001

Plain-text details taken from the first reference:

One can set a password to protect the boot menu entries and the command-line
shell of the GRUB boot manager (see the official manual and the Red Hat
manual). This is an additional security measure to be used along with a
BIOS/UEFI password (e.g., to protect corporate computers from unprivileged
users trying to leverage their physical access to boot another operating
system or to escalate the privileges in an installed operating system).

Under the hood, this feature is implemented as two GRUB commands: “password”
and “password_pbkdf2“. When one of these commands is issued with a proper set
of arguments, a user with a specified password (or its hash) is created. And
only those users listed in the “superusers” environment variable (when it’s
set by issuing the “set” command) are allowed to edit boot menu entries and
execute commands in the GRUB shell. (A physically-present user is required to
authenticate as a superuser when trying to edit a menu entry or trying to
enter the GRUB shell.)

In most cases, commands to set the “superusers” variable and to create
corresponding users are stored in the GRUB configuration file, “grub.cfg”
(which is more like a script, not a pure configuration file).

There were some vulnerabilities affecting the GRUB password protection
feature, like weak permissions for the GRUB configuration file that allowed
unprivileged users to obtain plain-text passwords and/or password hashes (for
example: CVE-2012-2314, CVE-2013-4577, and CVE-2021-3981), an integer
underflow (CVE-2015-8370), and even an improper string comparison
(CVE-2009-4128).

Now, there is one more: CVE-2023-4001.

This vulnerability allows unprivileged users with physical access to a
computer to bypass the password protection feature of the GRUB boot manager on
many (but not all) UEFI-based computers. In some uncommon setups, no
unprivileged access is required (so, physical access without an ability to log
in into an operating system is enough).

In theory, commands required to properly enable the password protection
feature (i.e., to create a user and to set a list of superusers) of the GRUB
boot manager can be stored in two locations: in the configuration file
embedded in the GRUB image (which is an EFI executable) and in the “external”
configuration file (which is most likely named “grub.cfg“).

In the UEFI Secure Boot world, GRUB images are signed, so they can’t contain
anything other than a hard-coded (vendor-defined) password or its hash (and,
hopefully, there are none). So, the corresponding commands have to be stored
in the “external” configuration file, “grub.cfg“.

Originally, on BIOS-based systems, this configuration was stored as a single
file in the same directory with the GRUB files.

But on UEFI computers this configuration became split between two files: the
first one in the EFI System Partition volume
(“/boot/efi/EFI/<vendor>/grub.cfg“; it’s usually a FAT12/16/32 file system)
and the second one in the “/boot” volume (“/boot/grub/grub.cfg” or
“/boot/grub2/grub.cfg“; it’s usually a file system not supported by the UEFI
firmware: e.g., Ext2/4 or XFS). The latter will called “the main configuration
file” here.

A thorough explanation of this new scheme can be found here:
https://fedoraproject.org/wiki/Changes/UnifyGrubConfig.

When the GRUB password is set (e.g., using the “grub2-set-password” tool),
it’s written to the main configuration file. And the first configuration file
is just a simple script to locate and execute the main configuration file (as
shown on the screenshot below).

<screenshot>

A configuration file found in the EFI System Partition (CentOS Stream 9)

If the password-related commands were stored in the first configuration file,
there would be no issue described in this post. But they are stored in the
main configuration file, which is found and then executed by the first
configuration file.

What if the main configuration file isn’t found? The GRUB boot manager will
spawn its shell.

Interestingly, we can force the main configuration file to “disappear” (at
least on some systems) when the first configuration file is executed. So,
there would be no password prompt (because no password-related commands are
ever executed after the power-on event) and the GRUB shell will be immediately
available to a physically-present user.

The UUID is the key! The main configuration file is located using a predefined
path: “<device>/grub2/grub.cfg” (as shown on the screenshot above). Here,
“<device>” is a volume found by its file system UUID using the “search”
command.

And duplicate file system UUIDs pose a security problem…

If there are two file systems sharing the same UUID, one of them is the real
“/boot” volume and another one is an empty volume, the GRUB boot manager
could, under some circumstances, pick a wrong device as containing the main
configuration file. And if there is no main configuration file stored (that
empty volume case), the GRUB shell is spawned.

Internally, the “search” command tries every partition on every block device
until a specified signature (a file system UUID in this case, but the command
also supports searching by a volume label and by a file) is found.

All block devices are tried in the same order as returned when enumerating
their EFI handles (“hd0”, “hd1”, “hd2” and so on, “hd0” corresponds to the
first EFI handle returned when enumerating EFI block devices). Some UEFI
implementations enumerate non-removable drives before removable ones, while
others do exactly the opposite (e.g., my Lenovo laptop exposed this behavior;
the UEFI implementation of VirtualBox with USB3 support enabled enumerates USB
sticks before internal drives too).

So, if an attached removable drive (like a USB stick) becomes “hd0” in the
GRUB boot manager (and the computer’s internal drive is “hd1” in that case),
it’s possible to bypass the GRUB password protection feature by placing an
empty file system with the same UUID as the real “/boot” volume onto that
removable drive and attaching it to the computer before the boot. During the
boot, the GRUB boot manager will simply spawn its shell, without even asking
for a password (and without changing the boot order, of course).

Unprivileged users can learn the UUID value of the “/boot” volume using the
“lsblk” tool (because file system UUIDs are exposed to unprivileged users).

Here is a video demonstrating the attack: https://drive.google.com/file/d/1mMlEIgfnUKIgaOEBNmtWuRo7RUAqjDrT/view?usp=sharing.

It should be noted that some Linux distributions provide enough debug output
in a separate console, so a necessary UUID can be obtained from there (and no
unprivileged access to the operating system is required in this case).

Timeline

 2023-04-03: the vulnerability was discovered by me.
 2023-07-17: the vulnerability was reported by me to Red Hat.
 2023-10-17: an initial fix is available for testing.
 2023-10-18: an issue was discovered by me in that fix (an attacker could
bypass an additional check implemented by the patch by attaching 10 removable
drives to the computer, if that number of removable drives is supported by the
firmware).
 2023-10-30: a new fix is available for testing.
 2023-10-31: two issues were discovered in that fix (one issue is a “huge”
heap overflow introduced when working with strings in the patched code,
another issue is a minor out-of-bounds write of a null byte).
 2023-10-31: a final fix is available.
 2023-11-23: the disclosure date is agreed upon — 2024-01-15.
 2024-01-12: the vulnerability is disclosed by Red Hat.
 2024-01-15: this post has arrived.

Fix

A fix proposed by Red Hat implements a new argument to the “search” command,
which restricts the UUID scan to the block device used to launch the GRUB boot
manager. This means that the “/boot” volume must reside on the same drive as
the EFI System Partition.

An alternative (but not implemented) approach would be to use something that
isn’t exposed to unprivileged users as a signature to locate the “/boot”
volume. This could be a file with a random name residing in a directory with
restricted permissions.