GRUB2 UEFI SecureBoot Vulnerability: 'BootHole'
debian.org
debian.org
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
Not that it is a bad thing, some people do prefer that kind of stability. But then, why complain about that?
Btw, Intel did plan to remove CSM (legacy BIOS compatibility) with Tiger Lake and require UEFI class 3. We will see if they will follow through. Then the procedure WILL change, and we will hear from people who didn't expect it.
It does not have magic sectors on disk, in MBR for boot loader, on somewhere in dummy area of the filesystem for grubenv, everything happens on the EFI partition and with EFI variables (stored in nvram). Creating bootable EFI media means having vfat-formatted filesystem and copying files there. No need for tools like Rufus.
Your firmware would find it at boot time, and allow you to boot from it; most UEFI implementation have boot manager built-in.
1. Boot into a working-enough live system - only way to improve this is to put a recovery system on the same system, but then you risk making it unbootable as well
2. Mount needed filesystems - depends completely on what filesystems there are, which is extremely variable; my only thought would be to use labels and hope that the installed system labels root/boot/efi the way you expect
3. Mount special filesystems - this is possible to automate; ex. arch-chroot (https://wiki.archlinux.org/index.php/Chroot#Using_arch-chroo...) does it, but that requires that you know what you need, so it's going to be brittle unless you stick with distro-provided tools (hence, arch chroot)
4. Fix the system - again, totally depends on what happened and how it should be set up; yes, in the trivial case you could make a "just-reinstall-grub.sh", but it'll fall apart for non-trivial setups
If every system looked the same, then yes you could make a livecd that automatically booted, set up mounts, chrooted in, fixed grub, and rebooted out, but this is the world of Linux-based systems so even within a single distro there's worlds of difference.
Windows' repair mechanisms also only work in the common case and you have resort to quite similar CLI stepss when they don't.
for ii in dev dev/pts proc sys ; do mount --bind /$ii /target/$ii ; done
Unmount: umount /target/dev/* /target/* /target
This can also be useful on newer systems where systemd systems need to be chrooted.
systemd-nspawn --directory /target --boot -- --unit rescue.target
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.
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)
Maybe a proper rj45 would work
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.
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
Can it boot fully-encrypted disks (by chainloading GRUB, for example)?
I have a setup where I moved /boot of the encrypted luks partition to the esp and boot from there using a custom entry in rEFInd
Never once has the Linux boot manager/loader (either the original GRUB or rEFInd) been broken, by a Windows update or otherwise.
Windows of course has been well documented to happily overwrite any MBR bootloaders when you install it, but even that doesn't happen in a UEFI environment. Windows, rEFInd, GRUB, and whatever else you may have installed all have their own folders. It might change the default, but restoring your own choice is literally a matter of copying a single file.
EFI has plenty of problems of its own, but this is one it solved pretty well.
The workaround for me was the "boot from file" boot option, where I would be able to walk the directories in the efi partition and start grub. Once this was done, it was back in the boot option list.
I've had it nuke my bootloader a few times when I used to sill dualboot (now full Linux).
One time the windows installer confused the encrypted LVM disk with a corrupted NTFS partition (because it had an NTFS partition on it at some point and underlying data wasn't wiped properly) and tried to fix it. Suffice to say, that required a back restore, so now all my encrypted disks have a 100MiB NTFS buffer partition for Windows repair to fuck around it (until I removed dualboot, I occassionally found remnants of an attempted repair in them)
If you want to learn more about how a typical Linux system is organized, but don't have the time or patience to go through the Linux From Scratch book [2], installing and configuring Arch once is pretty insightful and also kind of fun.
It's great that the modern Linux install process is so easy, but one drawback is that it also makes it easy to gloss over how the system is put together.
I just meant that it can be insightful to put together a toy system from scratch, so that you can learn (at your own pace) how chroots work, learn the conventions around manually recreating your root hierarchy in /mnt, learn what systemd services you actually need because you need to manually turn them on, rather than having a bunch of stuff you don't understand enabled by default, etc.
Many years ago I had disk error problem and could not boot. I tried a popular, Linux-based "system rescue" CD and it could not boot without accessing the disk. I tried my own "live" NetBSD USB stick and booted up no problem. No disk access needed.
I stayed away from Linux for many years as a result of experiences like that. I have been using Linux lately and I continue to find more stuff like this that would just never happen on BSD.
I do not understand why people use grub, let alone grub2. There are plenty of other bootloaders. What is wrong with syslinux?
But yeah for normal desktop usage… there's rEFInd.
It can pick up Windows for multiboot and is straightforward to configure (can even be configured from a windows live disk if you mount that FAT partition).
[1] https://wiki.archlinux.org/index.php/Arch_boot_process#Boot_...
In most gummiboot setups, your kernel will be on the ESP partition along with everything else, so it doesn't matter what FS the root is.
The lack of support for MBR or BIOS doesn't matter much either, systemd-boot requires a 64bit System and most 64-bit systems that are still around and largely used (or actively sold) have a UEFI that supports GPT. If you absolutely need to, systemd-boot supports booting from a GPT that has a MBR wrapper.
So while the table looks like systemd-boot lacks support for a lot of things, the reality is that when you setup systemd-boot a lot of these columns simply don't matter
Hence the table being slightly misleading.
For example, it also mentions that EFISTUB means you can't boot on btrfs and friends anymore. But it's the same limitation, initramfs and kernel need to be on the ESP, everything after that is up to the initramfs to bring up.
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...
[2] https://cryptsetup-team.pages.debian.net/cryptsetup/encrypte...
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.
> 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.
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.)
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.
I don't know if this meets your definition of "actually secure" but it does mitigate the issues around initramfs etc.
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.
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...).
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.
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.
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.
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.
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.
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.
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?
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.
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.
If you are talking about editing config, you just disable it in the config (editor no) and then nobody can just add an entry at random during the boot process.
Seems pretty simple to me.
I found the editor option, but the issue was that the config file could be edited offline to enable it again. Stripping the whole feature out of the binary solved the issue for what I needed. I guess it just goes to show there's a broad spectrum of interpretations of tamper resistance. If you're using dm-verity for example, you want to protect your cmdline parameters to at least the level of security offered by secure boot.
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.
[0]: https://safeboot.dev
In Ubuntu and Fedora you can’t load unsigned kernel-modules when using secure boot.
How does that not increase security?
FWIW, I double-checked with a Fedora developer; the above statement is incorrect. Fedora uses it (Secure Boot) to enforce lock-down on the kernel and then require code signing, etc.
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.
Severity was reported as "Moderate", but its enough that we'll patch soon.
The mighty GNU moos MÄGYCK! Now hurry, put your seven-league boots on :-)
Grub is not signed by Microsoft CA, only shims are. So the exploit is installing an old shim and a vulnerable grub.
turns out apt-get uninstalled the signed grub2 image