
GRUB2 UEFI SecureBoot Vulnerability: 'BootHole' - edward
https://www.debian.org/security/2020-GRUB-UEFI-SecureBoot/
======
anonymousiam
I wish the process of restoring a non-booting Debian-derived system were
easier. After needing to do it on several dual-boot systems, I keep the
procedure handy now. Here it is for posterity:

1) Boot Linux from your distro CD or DVD

2) Get a shell

3) Mount your normal Linux partitions. (Make sure you know where they are. The
following example assumes / on /dev/sda1 and /boot on /dev/sda2.) E.g. mount
/dev/sda1 /mnt Note: If you have a separate partition for /boot, then mount it
too: mount /dev/sda2 /mnt/boot

4) Mount the special nodes: mount --bind /dev /mnt/dev && mount --bind
/dev/pts /mnt/dev/pts && mount --bind /proc /mnt/proc && mount --bind /sys
/mnt/sys

5) Change your shell's root: chroot /mnt

6) Re-install grub: grub-install /dev/sda

7) Update the grub boot menu: update-grub

8) Undo chroot: exit

9) Unmount the special nodes: umount /mnt/dev && umount /mnt/dev/pts && umount
/mnt/proc && umount /mnt/sys

10) Remove media and reboot

~~~
jeroenhd
This strongly depends on the issue though. In most dual booting cases I've had
to deal with recently, a single efibootmgr command was enough.

Windows and some Linux distros like to replace the fallback EFI command and
the two can conflict every now and then. By properly configuring the UEFI to
pick the right OS at boot (sudo efibootmgr -o 0001,0000 or something like
that) should be enough.

If you're still using MBR or you have a shitty motherboard with bad UEFI
support you're right that you're still forced to do a full Grub reinstall.

I've had to do recovery on a non-booting Windows machine that broke after a
recent update and it was just impossible to recover. Some file on the FS was
corrupted, but SFC couldn't recover it and wouldn't report what file was
corrupted. Rebooting into recovery takes forever, boot recovery constantly
fails and the only saving grace is the "reinstall Windows" that uses a
complete reinstall as a fix for a broken OS.

Yes, fixing Linux is difficult, but at least it's doable. On Windows you're
basically stuck with the two or three auto-recovery options or an OS +
software reinstall.

I can't speak for macOS but I can't imagine it being much easier (especially
because the limited variety of macOS hardware makes it more unlikely for the
OS to fail catastrophically because that's easier to test for).

It shouldn't be too hard to create a Linux boot ISO that lists installed
operating systems and then automounts them for recovery. It's only a matter of
parsing GRUB config files + fstab + crypttab and some predefined mount
patterns for distros after all.

~~~
arprocter
Mac lets you reinstall the OS from the recovery partition without losing data

[https://support.apple.com/en-us/HT204904](https://support.apple.com/en-
us/HT204904)

If the recovery partition is toast you can do a clean install over wifi -
Option-Command-R or Shift-Option-Command-R

(would only work over an open wifi the last time I did it)

~~~
jeroenhd
Does this include programs and settings? Windows lets you reinstall with data
as well, but installing every single program and getting it set up all over
again takes forever, that's my main problem with the Windows recovery process.

The install over the internet is a nice touch, though I don't expect that
feature to ever make it into normal computers because it would probably force
manufacturers to put a minimal Windows installer in their UEFI.

~~~
arprocter
>Does this include programs and settings?

Yes, I believe so - I'm guessing this is due to things being more siloed

I should also mention it won't let you choose an OS version, although it does
say the name of the one that will be installed

------
g_p
For anyone looking at how to mitigate against this, a "defence in depth"
approach using grub-mkstandalone [1] has always been wise. If you're building
an appliance-style system, or just want to prevent abuse of Grub features on a
secure boot system, a standalone image lets you "lock" the grub config file
inside the signed binary. Once you use non-default secure boot signing keys,
this attack would appear to be prevented, by avoiding the changing of the
config file. The config file can be adjusted to prevent using edit mode in
Grub at runtime.

I currently have a standalone grub image set up, with fixed path/filename
kernel and initramfs in use, meaning I don't need to update the grub image
unless changing the config or updating grub itself. You can then combine this
with full disk encryption (dm-crypt + luks) over the entire disk including
/boot [2], and get a pretty safe setup, that would mitigate against this in
the first place, as well as any other attacks trying to tamper with
modules/fonts/config files for grub (as they get wrapped into the signed grub
binary).

[1]
[https://wiki.archlinux.org/index.php/GRUB/Tips_and_tricks#GR...](https://wiki.archlinux.org/index.php/GRUB/Tips_and_tricks#GRUB_standalone)

[2] [https://cryptsetup-
team.pages.debian.net/cryptsetup/encrypte...](https://cryptsetup-
team.pages.debian.net/cryptsetup/encrypted-boot.html)

------
devit
Note that secure boot trusting Microsoft's key is a completely useless
feature.

In addition to countless holes like these (since Microsoft signs software
written in C), and the fact that you need to already have compromised the
system, all that secure boot does is ensure that an unmodified kernel is
running; you can however have it run arbitrary user space, including for
instance running the user's previous OS in a VM or emulator and altering its
behavior arbitrarily, and thus it effectively provides no protection
whatsoever.

~~~
bscphil
Yes, because of Microsoft's key signing program, UEFI security is already
fatally flawed even without this new issue. See for example
[https://habr.com/en/post/446238/](https://habr.com/en/post/446238/)

> In this article we proved the existence of not enough reliable bootloaders
> signed by Microsoft key, which allows booting untrusted code in Secure Boot
> mode. Using signed Kaspersky Rescue Disk files, we achieved a silent boot of
> any untrusted .efi files with Secure Boot enabled, without the need to add a
> certificate to UEFI db or shim MOK.

------
noodlesUK
I’ve seen this on Twitter a couple times today. Is it even possible to involve
GRUB in a secure boot setup in a way that’s actually secure? I’ve never
encountered a Linux (other than gentoo, but that’s not exactly normal) where
the initramfs wasn’t in plaintext, and unsigned. You can get whatever
arbitrary code you want running as PID 1 from there. If you want secure boot,
the way that makes sense is to use your own keys and combine the initramfs and
command line with the kernel, and sign that with your secure boot keys. I
don’t know why there isn’t a super slick way of doing that, but it is
definitely smooth and more secure. Wasn’t EFI supposed to free us from things
like GRUB anyway?

~~~
vladvasiliu
This is how my arch box is setup. I've done it by following some page on the
arch wiki [0].

There is only one binary containing the kernel itself, the kernel command line
and initrd that is signed and booted directly by the EFI. There's no
bootloader in the grub sense.

That being said, I can see how one could argue that that's "not exactly
normal", in the same sense that gentoo isn't.

I'm surprised this isn't more widespread, especially since most UEFI PC's I've
seen have a very practical way of choosing which OS to boot.

[0]
[https://wiki.archlinux.org/index.php/EFISTUB](https://wiki.archlinux.org/index.php/EFISTUB)

------
userbinator
I've never liked "secure boot", neither its "security" nor its user-hostility.

 _All of the Linux distributions shipping with Microsoft-signed copies of shim
have been asked to provide details of the binaries or keys involved to
facilitate this process._

It's sad to see Linux distributions, even the more "principled" and presumably
non-corporate ones like Debian, essentially bowing down to MS. As Linus
Torvalds said when this whole secure boot thing started: "I will not change
Linux to deep-throat Microsoft."

(Linux hates UEFI too, and I agree with him on that point as well.)

------
aibrahem
Besides power management, this is one of my biggest bit peeves with Linux
distributions now.

I don't understand why there isn't a single distribution that offers a full
Secure Boot implementation or LUKS Encryption with a password sealed by the
TPM out of the box.

Also, there seems to be a lot of misconception about what Secure Boot does,
unlike what the name implies, Secure Boot doesn't inherently provide any extra
security or protection. It's just a mechanism to sign the software running on
the system.

To make the most out of Secure Boot the distributions would need to sign and
lock the boot-loader, kernel, and initrd, Then they could seal the LUKS
encryption passphrase using the TPM, so if anybody tries to run any
unauthorized software, they wouldn't be able to access the data on the drive.

It would be very similar to what windows does with bit locker; your hard-drive
is automatically decrypted on system boot without entering any passwords.

~~~
xvilka
There is - Heads[1].

[1] [https://github.com/osresearch/heads](https://github.com/osresearch/heads)

------
cesarb
> Most vendors are wary about automatically applying updates which revoke keys
> used for Secure Boot. Existing SB-enabled software installations may
> suddenly refuse to boot altogether, unless the user is careful to also
> install all the needed software updates as well. Dual-boot Windows/Linux
> systems may suddenly stop booting Linux. Old installation and live media
> will of course also fail to boot, potentially making it harder to recover
> systems.

That means: with Secure Boot enabled, once the machine's firmware is updated,
_all_ currrently existing Linux install media will stop working. Users have to
either wait for new install media to be released, or disable Secure Boot. At
least it's still possible to disable Secure Boot, or enroll your own keys;
will that still be the case once x86 CPUs start being replaced with ARM CPUs?
IIRC, Microsoft requires that systems with ARM CPUs _not_ allow disabling
Secure Boot or enrolling your own keys
([https://www.softwarefreedom.org/blog/2012/jan/12/microsoft-c...](https://www.softwarefreedom.org/blog/2012/jan/12/microsoft-
confirms-UEFI-fears-locks-down-ARM/)).

~~~
cmurf
The requirement to disallow users disabling UEFI Secure Boot on ARM, applies
to the Windows hardware certification spec. There's no requirement that a
vendor must follow that spec in order for the hardware to run Windows. It is a
spec designed to tie co-marketing of Windows and your product, e.g. "made for
Windows" with minimum compatibility standards (or at least Microsoft's idea of
minimums). For example it also requires a TPM 2.0 be present and enabled.

------
shasheene
> With the sole exception of one bootable tool vendor who added custom code to
> perform a signature verification of the grub.cfg config file in addition to
> the signature verification performed on the GRUB2 executable, all versions
> of GRUB2 that load commands from an external grub.cfg configuration file are
> vulnerable.

Perhaps the ability to sign grub.cfg should be added to GRUB2, and this
feature should be enabled by default.

Though this would mean rather than allowing users to enter arbitrary kernel
boot options (and being able to leverage buffer overflow exploits), a bunch of
preset menu items would have to be present. Alternatively, this signed
grub.cfg can have its boot menu password-protected. (If I recall correctly
individual menu items cannot be password protected.)

Lowering the GRUB2 attack surface area is a good idea, so hopefully these
suggestions get deeply considered.

~~~
mjg59
How would that work? If the public key is baked into the signed grub, the only
person who can sign the config is whoever built grub. If the keypair is
generated locally and the public half put on the ESP, an attacker can just
replace it. Signed config works if you never need to modify the config, but
for a general purpose OS you need to be able to modify the config.

~~~
shasheene
Sorry, I forgot that typical grub.cfg contains the root partition's UUID (and
at least historically, the partition device node). While it is possible to
configure GRUB to scan for a root partition rather than using a UUID, this is
less secure (eg, GRUB residing on your hard drive could then accidentally
select your root partition residing on a USB stick containing Linux live
media).

Good point that in general, the operating system vendor does not know the
grub.cfg on an installed system, and that an attacker with direct access to
the ESP can modify the files that are present there.

A static grub.cfg that selects "the Linux root partition is the first
partition on the device on which this GRUB bootloader is installed on" would
work. I don't believe GRUB supports this kind of behavior (maybe it should).
It seems worthwhile and possible to design a mechanism where a simple grub.cfg
can be signed by the operating system vendor. Disabling the ability to
arbitrarily modify kernel boot options on a general purpose operating system
is not a big deal, and could be mitigated with extra GRUB boot menu items.

------
young_unixer
Does anyone actually use secure boot in the intended way? As in: adding a key
to the register and then booting a binary with that key.

I'd guess everyone simply disables secure boot and installs their system.
Then, what is the point of secure boot?

I'm pretty ignorant about this stuff, but secure boot makes no sense to me.

------
moonchild
Secure boot should not be trusted.

If you want to be secure against evil maid attacks, use full disc encryption
and keep the bootloader on a usb drive on your person.

------
lkmsq
Does anyone else think that LILO was more intuitive?

I feel at the whim of my BIOS with this whole efibootmgr situation. My laptop
was suddenly unbootable and I had to repair everything manually. I had not
changed the system at all, so something must have changed in the BIOS.

Never happened with LILO, which also was better documented.

~~~
g_p
I see where you're coming from here - to my mind there's 3 issues here.

1 - The increased complexity of the UEFI stack having many components, and no
good simple explanation of it to bring people up to speed with (at least that
I'm aware of) - UEFI boot introduces NVRAM which is a fairly big change from
the old way, and introduces the ESP partition for storing bootloaders. Fairly
significant changes, coupled with not every UEFI firmware (i.e. BIOS)
implementing things in the same way - not every motherboard gives the same
options to users for managing boot entries in NVRAM.

2 - The introduction of secure boot at the same time, and the confusion around
shim and similar for running Linux. Don't start on the complexity of enrolling
your own keys and how some motherboards let you do it directly, while others
make you use keytool or another efi binary to do it.

3 - Bootloaders becoming more and more complex as a result of secure boot
requiring them to sign all their code, pushing them towards external configs
and modules, coupled with multi boot becoming a native feature since the ESP-
based loader needs to find the right config and load it, then find the right
filesystem and go from there.

Much of the parts of part 3 were needed for LILO and MBR, but it feels like
fewer moving parts were in play.

------
stragies
Aaaand it's gone ... As in the ability to run custom/new kernel-modules on a
system with secure boot enabled, without the system considering itself "too
tainted" to run certain apps/binaries, that require the system to be
"immaculate".

This would also mean, that the old adage "If you can touch it with your hand,
you can run unsigned code on it, given the right tools & time." wont be true
anymore. That's why server room doors have access control systems.

But the owner of the device should always be able to modify/circumvent/audit
any part of the boot process.

All PCs since the first ones with ME/Trustzone, and all phones in existence
are already locked down to some degree, making some kinds of R&D difficult. I
see the proposed changes as something, that will ultimately lead power users
to have even less control over their own systems.

Or am I wrong here? Please, can somebody provide evidence to the contrary?

------
kd913
Can distros maybe consider moving to systemd-boot at some point? Systemd is
already built in and can handle things like mounting pretty easily and simply.

It is a lot leaner than grub, doesn't use a billion superfluous modules. That
and it is a lot easier to prevent tampering compared with the cumbersome
nonsense that is grub passwords.

Oh and it enables distros to gather accurate boot times and enables booting
into UEFI direct from the desktop.

It works with secureboot/shim/Hashtool. Also each distro has it's bootloader
entries in separate folders to avoid accidental conflicts.

~~~
g_p
Honest question - is it really significantly easier to prevent tampering with
systemd-boot? I had a look at this recently, and ended up having to modify the
source (admittedly quite easily though) to avoid relying on important
parameters in the config file.

I wanted to disable editing cmdline and similar from the prompt, and ended up
simply compiling that feature out (along with others). I'm not sure if there's
an easy way to fix this either, since the obvious way to "secure" the
bootloader is via a config file, but we really need to assume the config file
is editable by an attacker, and therefore compromised.

That you don't have to go build a standalone EFI image to get modules and
similar embedded into the binary is certainly safer, but I would say most
stock Linux bootloaders are still a fair way from being easy to prevent
tampering on.

~~~
Nextgrid
I think the main advantage here is less about tampering (if we assume neither
of these bootloaders have bugs then a GRUB2 password should be as secure as
its systemd-boot equivalent) but more about the fact that systemd-boot doesn't
have decades of legacy cruft accumulated that's irrelevant for UEFI and thus
is less prone to having disastrous bugs.

~~~
g_p
Totally agreed on the reduced cruft - when I was modifying the codebase I felt
quite comfortable with the code and it's readability. Despite it being someone
else's code, it was understandable and intuitive and I felt at home with it. I
could see what to patch and edit, and it worked as expected without surprises.
Important for something as critical as a bootloader to use principle of least
astonishment.

I only picked up on tamper resistance based on the GP as I was wondering if I
missed something and ended up patching unnecessarily or was misunderstanding
something. It's also possible I'm using a stricter definition of tampering, as
in my project I considered removing the SSD and modifying the ESP as being "in
scope". I recognise for many that's not in scope, and where you fall back to
relying on FDE to prevent booting the system anyway.

------
codethief
Speaking of SecureBoot and how practically no Linux distribution actually
makes use of its potential (in terms of increasing security), does anyone here
have any experience with SafeBoot?[0] It looked pretty interesting to me,
though mounting the rootfs read-only didn't seem go well with how most Linux
distributions these days still require you to change files in / on an almost
daily basis.

[0]: [https://safeboot.dev](https://safeboot.dev)

~~~
josteink
> Speaking of SecureBoot and how practically no Linux distribution actually
> makes use of its potential (in terms of increasing security)

In Ubuntu and Fedora you can’t load unsigned kernel-modules when using secure
boot.

How does that not increase security?

~~~
codethief
Ubuntu's (and to my knowledge also Fedora's) boot chain is not fully
validated. An evil maid can easily swap out the initramfs.

------
henearkr
Any protection that makes sense would use a real encryption mechanism, not an
obfuscation like UEFI. The "secret" for UEFI SecureBoot is embedded in the
"secured" system, so it is already in the wild (i.e. outside of the brain of
the user) - not a secret at all.

So I believe that a meaningful modern security setting would be based on some
dm-crypt/luks ciphered storage and a passphrase to unlock it.

------
blaser-waffle
I saw a similar report from Red Hat not long ago. Like ~30 min ago.

Severity was reported as "Moderate", but its enough that we'll patch soon.

------
LargoLasskhyfv
[1] [https://eclypsium.com/2020/07/29/theres-a-hole-in-the-
boot/](https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/)

The mighty GNU moos _MÄGYCK!_ Now hurry, put your seven-league boots on :-)

------
Shorel
Meanwhile, I just disable secure boot to be able to use the Liquorix kernel.

------
PaulBGD_
So this says it impacts Windows, but it seems to only be an issue with grub?

~~~
efreak
There are only two references to Windows in the article. The first one says
Microsoft might push an update to the UEFI revocation list blacklisting the
vulnerable binaries. The second mentions that _dual-boot_ systems are
affected, basically a reminder that if you're dual-booting with SecureBoot
enabled, you need to make sure you've got the new non-vulnerable binaries
installed on Linux before any updates to the revocation list (applied in the
previously-mentioned possible Windows update) prevent you from booting it.

~~~
SAI_Peregrinus
And that if the attacker has admin and physical access to Windows they can
just install GRUB from there, then exploit that to install a rootkit to
persist their access.

~~~
usr1106
Do you really need physical access for that?

Grub is not signed by Microsoft CA, only shims are. So the exploit is
installing an old shim and a vulnerable grub.

------
thetanil
So this just caused me to google 'arch boothole' and umm... NSFW

------
blibble
I applied this update and my machine didn't boot afterwards

turns out apt-get uninstalled the signed grub2 image

~~~
Avamander
The signed image's package is only removed if you have a conflict you somehow
manually created. What command did you actually run?

