[HN Gopher] GRUB2 UEFI SecureBoot Vulnerability: 'BootHole'
___________________________________________________________________
GRUB2 UEFI SecureBoot Vulnerability: 'BootHole'
Author : edward
Score : 79 points
Date : 2020-07-29 18:32 UTC (4 hours ago)
(HTM) web link (www.debian.org)
(TXT) w3m dump (www.debian.org)
| rodgerd wrote:
| Oh hey: C programmers and fucking up user text input. A classic
| security blunder. For about as long as I've been alive.
|
| And yet it's the PHP or Visual Basic programmers that cop all the
| shit from language elitists.
| [deleted]
| kd913 wrote:
| 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 wrote:
| 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.
| Shorel wrote:
| Meanwhile, I just disable secure boot to be able to use the
| Liquorix kernel.
| cesarb wrote:
| > 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 (htt
| ps://www.softwarefreedom.org/blog/2012/jan/12/microsoft-c...).
| cmurf wrote:
| 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.
| PaulBGD_ wrote:
| So this says it impacts Windows, but it seems to only be an issue
| with grub?
| efreak wrote:
| 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.
| g_p wrote:
| 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...
|
| [2] https://cryptsetup-
| team.pages.debian.net/cryptsetup/encrypte...
| devit wrote:
| 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.
| johncolanduoni wrote:
| Linux does have mechanisms to prevent changes to userspace (in
| particular the Integrity Measurement Architecture), but you're
| right that distributions don't generally implement these in a
| useful way. Some more locked-down distributions like Google's
| Container Optimized OS do use these to prevent offline
| userspace changes.
| the8472 wrote:
| There are some android features that recently have been
| upstreamed to the mainline kernel like dm-verity that allow you
| to boot into a read-only, verified userspace.
| LargoLasskhyfv wrote:
| [1] https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/
|
| The mighty GNU moos _MAGYCK!_ Now hurry, put your seven-league
| boots on :-)
| anonymousiam wrote:
| 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
| freeone3000 wrote:
| This is essentially identical to the procedure I did 15 years
| ago. What's the issue?
| tux3 wrote:
| I don't think GP is complaining because the procedure changed
| in the last 15 years, but precisely because it didn't.
| Surely, there's room for improvement.
| vetinari wrote:
| Well, he still doesn't use UEFI. He could, it has been
| available for more than decade (i.e. better part of those
| 15 years), so the procedure didn't change because he has
| chosen so.
|
| 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.
| yjftsjthsd-h wrote:
| Wouldn't UEFI make it _more_ complex, since you now
| potentially need to mount / and /boot and /boot/efi all
| separately before you can fully recover grub?
| vetinari wrote:
| Not more complex, but different.
|
| 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.
| yjftsjthsd-h wrote:
| I think the issue boils down to the fact that it depends
| almost completely on exactly how the system is put
| together. I mean, the process is:
|
| 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.
| the8472 wrote:
| Semi-automating the common cases with a GUI would
| probably help many of the less sophisticated users. E.g.
| scan the existing system for partitions and ask them
| which one they want to repair.
|
| Windows' repair mechanisms also only work in the common
| case and you have resort to quite similar CLI stepss when
| they don't.
| jeroenhd wrote:
| 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 wrote:
| Mac lets you reinstall the OS from the recovery partition
| without losing data
|
| 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)
| manjalyc wrote:
| rEFInd can automatically detect linux, Windows, and mac
| partitions and boot them. You could just install it to a usb
| stick and use it whenever necessary.
| yaantc wrote:
| After several Win10 upgrades nuked grub on a dual boot system,
| I have found a much simpler process. Create a rEFInd [1] USB
| boot key once and for all. Then whenever grub is hosed, boot on
| this key: rEFInd will find the Debian partition and allows to
| run it directly. Then once in Debian just do an "update-grub"
| to fix things.
|
| [1] https://www.rodsbooks.com/refind/getting.html
| manjalyc wrote:
| You could just install rEFInd and make it the default
| bootloader with its auto find mode enabled.
| boardwaalk wrote:
| Man, I'm glad ArchLinux has arch-chroot to do this for you!
| mjevans wrote:
| I usually do the bind mounts a little differently:
|
| 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
| ohazi wrote:
| This is essentially the process used for installing the base
| system in Arch. As usual, the Arch Linux wiki page on this
| topic [1] is a good resource, even if you're using a different
| system.
|
| 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.
|
| [1] https://wiki.archlinux.org/index.php/Installation_guide
|
| [2] http://www.linuxfromscratch.org/lfs/
| yjftsjthsd-h wrote:
| I mean, it's just a chroot; it's the basic working "run a
| system without booting from it" that underlies a lot of base
| system tinkering and fixing.
| ohazi wrote:
| There are lots of people who have used Linux for years but
| have never actually gone through this exercise. It's not
| very fun to have to do it for the first time when an
| important system fails to boot.
|
| 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.
| pwdisswordfish2 wrote:
| Why is the Debian-derived system non-booting?
|
| 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?
| cmurf wrote:
| This isn't applicable to a UEFI Secure Boot system, where the
| shim and grubx64 binaries are distribution signed and installed
| from the package - not via grub2-install, which on UEFI
| produces an unsigned binary and will not boot under UEFI Secure
| Boot.
| moonchild wrote:
| 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.
| blaser-waffle wrote:
| 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.
| blibble wrote:
| I applied this update and my machine didn't boot afterwards
|
| turns out apt-get uninstalled the signed grub2 image
| YtvwlD wrote:
| That's why you should be careful when using dist-upgrade or
| full-upgrade. safe-upgrade wouldn't remove packages.
___________________________________________________________________
(page generated 2020-07-29 23:00 UTC)