|
|
Subscribe / Log in / New account

A long list of GRUB2 secure-boot holes

Several vulnerabilities have been disclosed in the GRUB2 bootloader; they enable the circumvention of the UEFI secure boot mechanism and the persistent installation of hostile software. Fixing the problem is not just a matter of getting a new GRUB2 installation, unfortunately. "It is important to note that updating the exploitable binaries does not in fact mitigate the CVE, since an attacker could bring an old, exploitable, signed copy of a grub binary onto a system with whatever kernel they wished to load. In order to mitigate, the UEFI Revocation List (dbx) must be updated on a system. Once the UEFI Revocation List is updated on a system, it will no longer boot binaries that pre-date these fixes. This includes old install media."


From:  John Haxby <john.haxby-AT-oracle.com>
To:  oss-security-AT-lists.openwall.com
Subject:  [oss-security] multiple secure boot grub2 and linux kernel vulnerabilities
Date:  Wed, 29 Jul 2020 17:57:44 +0100
Message-ID:  <29B1C52A-3781-4893-BBB3-9345E98B83DC@oracle.com>
Archive-link:  Article

[This message expands slightly on the post to the distros list on 2020-07-20.]

Hello All,

There are several CVEs both in GRUB2 and the Linux kernel (details
below) that compromise UEFI Secure boot and kernel lockdown.

 * These bugs allow unsigned code to be booted and run on hardware
   configured to prevent that.

 * Affected vendors will be publishing fixed, re-signed shim, grub and
   kernels to allow systems to continue to boot post-mitigation.
   Details of exactly what is published will vary from vendor to
   vendor.

 * The actual mitigation is a UEFI Revocation List update that
   prevents exploitable binaries from loading. This list will be
   available from: https://uefi.org/revocationlistfile soon.  Vendors
   may also include this in an updated release of a dbxtool package.

 * In addition to the Microsoft Key Encryption Key (KEK)-signed UEFI
   Revocation List updates, hardware vendors may also issue their own
   updates signed with their own KEKs.  Again, this will vary from
   vendor to vendor.

Exploiting these flaws require a significant level of access to a
system. The flaws would allow, for example, a nefarious kernel to hide
a rootkit or similar to be loaded onto a system that has UEFI Secure
Boot enabled. It is important to note that updating the exploitable
binaries does not in fact mitigate the CVE, since an attacker could
bring an old, exploitable, signed copy of a grub binary onto a system
with whatever kernel they wished to load. In order to mitigate, the
UEFI Revocation List (dbx) must be updated on a system. Once the UEFI
Revocation List is updated on a system, it will no longer boot
binaries that pre-date these fixes. This includes old install media.

Fully mitigating a system against these flaws should be done with the
clear understanding that old kernels and old install media will not
boot on a secure-boot system.

CVE details:

There are two kernel CVEs that are already public: CVE-2019-20908 and
CVE-2020-15780.  In addition there are the following GRUB2 CVEs:

CVE-2020-10713
    8.2/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
    This is the original flaw discovered by Eclypsium, also known as
    "BootHole" and is describe in Eclypsium's paper at
    https://www.eclypsium.com/2020/07/29/theres-a-hole-in-the...

CVE-2020-14308
    6.4/CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H
    grub2: grub_malloc does not validate allocation size allowing for
    arithmetic overflow and subsequent heap-based buffer overflow.

CVE-2020-14309
    5.7/CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:H/A:H
    grub2: Integer overflow in grub_squash_read_symlink may lead to
    heap based overflow.

CVE-2020-14310
    5.7/CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:H/A:H
    grub2: Integer overflow read_section_from_string may lead to heap
    based overflow.

CVE-2020-14311
    5.7/CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:H/A:H
    grub2: Integer overflow in grub_ext2_read_link leads to heap based
    buffer overflow.

CVE-2020-15705
    grub: avoid loading unsigned kernels when grub is booted directly
    under secureboot without shim
    6.4/CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H

CVE-2020-15706
    script: Avoid a use-after-free when redefining a function during
    execution
    6.4/CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H

CVE-2020-15707
    grub2: Integer overflow in initrd size handling.
    5.7/CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:H/A:H

jch


to post comments

A long list of GRUB2 secure-boot holes

Posted Jul 29, 2020 23:16 UTC (Wed) by xnox (guest, #63320) [Link] (3 responses)

I fixed the BootHole. 👢🐛

A long list of GRUB2 secure-boot holes

Posted Jul 30, 2020 3:22 UTC (Thu) by smitty_one_each (subscriber, #28989) [Link]

". . .but I did not fix the double-free. . ."

A long list of GRUB2 secure-boot holes

Posted Jul 30, 2020 7:24 UTC (Thu) by pjones (subscriber, #31722) [Link] (1 responses)

No, I am Spartacus!

A long list of GRUB2 secure-boot holes

Posted Jul 30, 2020 15:50 UTC (Thu) by HelloWorld (guest, #56129) [Link]

A long list of GRUB2 secure-boot holes

Posted Jul 30, 2020 3:03 UTC (Thu) by floppus (guest, #137245) [Link] (1 responses)

"Crafted grub.cfg file can lead to arbitrary code execution"... well, duh. If your grub.cfg file isn't trusted, your boot process isn't secure. It doesn't matter how authentic your kernel is, if there's no verification of the command line, initramfs, and the root filesystem.

The filesystem bugs sound serious, though.

A long list of GRUB2 secure-boot holes

Posted Jul 30, 2020 9:17 UTC (Thu) by grawity (subscriber, #80596) [Link]

A common way to use Secure Boot is by creating a "signed bundle" – a single signed .efi executable that contains a stub loader, the kernel image, the initramfs, and the (unchangeable) commandline. The stub loader ignores externally given parameters, it always uses the embedded ones. In this case grub.cfg doesn't need to be trusted to contain the correct options so it is often left on an unprotected FAT partition.

Together with this, I think there's the assumption that grub itself won't load unsigned .mod's and won't expose any memory-poking commands, in which case this would be safe, as you couldn't really put anything harmful in grub.cfg anyway. But the overflow bug breaks that assumption.

A long list of GRUB2 secure-boot holes

Posted Jul 30, 2020 14:03 UTC (Thu) by Yenya (subscriber, #52846) [Link] (2 responses)

FWIW, we've just updated GRUB (and some other packages as well, including shim and kernel) on one of our CentOS 8 machines. After reboot, BIOS got stuck trying to load the new GRUB. Rebooting from CentOS 8 rescue/install image, activating the network, and reverting the latest yum transaction (yum history undo) made the system bootable again.

For now we don't know exactly what went wrong. We even do not have secureboot enabled at all. Just a heads-up that the newest C8 GRUB packages might be buggy.

A long list of GRUB2 secure-boot holes

Posted Jul 30, 2020 14:59 UTC (Thu) by mattdm (subscriber, #18) [Link] (1 responses)

A long list of GRUB2 secure-boot holes

Posted Jul 30, 2020 15:08 UTC (Thu) by Yenya (subscriber, #52846) [Link]

Subscribed, thanks for the pointer.

A long list of GRUB2 secure-boot holes

Posted Jul 30, 2020 14:13 UTC (Thu) by kevincox (guest, #93938) [Link] (3 responses)

This made me think of UEFI signature expiry. It seems like a fundamental flaw in the system if signatures don't expire because as new payloads are signed you will have an ever-growing set of exploitable payloads that can be used to bypass UEFI. Even with a couple of blacklisted signatures it seems that there would be enough "forgotten" signatures floating around that no one yet reported a vulnerability in. I couldn't find any info on expiring signatures, apparently the signing certificate can expire (because it is a regular PKCS #11 cert) but most hardware doesn't check (and I'm sure trying to find the proper validation time against a hardware-access attacker would be a fun problem to solve). Does anyone have more information on this?

For organizationally controlled secure boot this probably isn't much of an issue. You can trust only your key and you sign a small amount of payloads. Ideally you would also rotate keys frequently as you updated the systems inside your org. In theory you could sign each update with a new key and blacklist the old key as soon as it is no longer live (and you know you don't need to roll back).

However for public systems like the Microsoft controlled keys this seems like a much harder problem. In theory Microsoft could rotate keys for systems running Windows however they have a couple of difficult-to-handle use cases (1) They need to keep install media working. (2) They sign open source boot-loaders.

For install media they could in theory use a separate much more slowly rotating key which would mitigate the problem with only moderate user annoyance (you can't reinstall an OS after N years) and with the relatively small number of installers published you could blacklist them if vulnerabilities are found being exploited. However this is already quite a large attack surface which probably isn't audited too closely! (You might get some benefits if you keep the install media and regular Windows bootloaders very similar, but still)

The third-party boot-loaders is even harder. You can't realistically rotate the keys as often as a lot of users won't be installing new secure boot keys and they probably expect their installers to continue working for a long time. I guess this is basically the installer problem with even less control.

Does anyone have more info on how Microsoft manages this? I guess there is a similar issue with phone manufacturers however the problem is much more similar to the organization model in that case.

A long list of GRUB2 secure-boot holes

Posted Jul 30, 2020 15:07 UTC (Thu) by excors (subscriber, #95769) [Link] (1 responses)

> I guess there is a similar issue with phone manufacturers however the problem is much more similar to the organization model in that case.

I think the typical solution on phones is that the firmware contains a version number, and the previous stage in the boot chain remembers the highest version number it has ever seen, and it refuses to load the new firmware if its version number is older. The version number is incremented whenever a sufficiently important security-related change is made. That works because the firmware is provided by a single vendor who can guarantee a linear sequence of firmware releases, and they always want users to install the latest version. It wouldn't work on PCs where e.g. users want to switch from Windows to Linux, or need to load third-party bootloader modules, unless you had some very complicated multidimensional version number and a lot of cross-vendor collaboration.

(At least that's the solution for the later stages of the boot chain. The root is probably a signing key stored in the SoC'S ROM or one-time-programmable memory, and if you want to update or revoke the key then you scrap the device and build a new one. The boot ROM code uses that key to verify the first stage bootloader, and I think typically there's no anti-rollback mechanism there. You just have to hope that people are really, really careful before signing any first stage bootloader. Subsequent stages can have their own sets of keys and anti-rollback mechanisms etc; there's no standardisation and they can do whatever they want. But they almost certainly don't have time-based expiry, because they don't have a battery-backed clock and won't know the time until they've fully booted and connected to the internet.)

A long list of GRUB2 secure-boot holes

Posted Jul 30, 2020 16:36 UTC (Thu) by Lennie (subscriber, #49641) [Link]

Matthew Garrett talked about that here too:

https://www.linux-magazine.com/Issues/2018/206/Trusted-Pl...

A long list of GRUB2 secure-boot holes

Posted Aug 7, 2020 22:34 UTC (Fri) by xnox (guest, #63320) [Link]

There are some timing support with dbt. However we cannot quite rely on them at least not yet. Specifically secureboot laptops shipped in 2008 may not have support for large nvram space, revocation of certificates by hash, revocation of specific signatures, or validation with time.

Windows signing key, and KEK keys are expiring soon.... And some things do validate them upon trying to load them.

For example my Dell sku from 2015 shipped with expired PK key. So I am not sure if I can actually rotate KEK key on my laptop unless somebody uses faketime and I set my laptop to 2014 to rotate to something newer.

Lots of things could have been done better. And here we are now.

A long list of GRUB2 secure-boot holes

Posted Jul 30, 2020 15:02 UTC (Thu) by dowdle (subscriber, #659) [Link]

RHEL 8 and CentOS 8 now have updates that break booting... in an effort to fix this. Oops.

https://bugzilla.redhat.com/show_bug.cgi?id=1861977

A long list of GRUB2 secure-boot holes

Posted Jul 30, 2020 22:19 UTC (Thu) by jschrod (subscriber, #1646) [Link] (2 responses)

Yesterday and today, I was offered GRUB updates for my Debian Buster (stable) systems.

Does anybody know if this update is affected by this problem, like the RHEL/CentOS update? I'm leaving for vacation tomorrow evening and don't want boot problems...

Maybe it's better to postpone the update?

TIA for any information,
Joachim

A long list of GRUB2 secure-boot holes

Posted Jul 31, 2020 14:22 UTC (Fri) by amacater (subscriber, #790) [Link] (1 responses)

No problem here on several machines.Debian works (much as ever). It's safe to do, as far as I can see. The fun will come when KEK invalidation comes round in due course and you can't boot from old media (or your UEFI hasn't had a firmware issued and your machine is invalidated ... or whatever happens.)

Whatever does happen, somebody will always blame Linux even if it's a broken UEFI implementation / they're updating a machine that hasn't been updated in three years or whatever.

I found https://www.debian.org/security/2020-GRUB-UEFI-SecureBoot/ to be quite a useful link to explain what is at issue here.

A long list of GRUB2 secure-boot holes

Posted Aug 2, 2020 18:00 UTC (Sun) by hmh (subscriber, #3838) [Link]

For Debian, most of the issues reported with the security update were linked to bad configuration at package update time, and an extremely annoying shortcoming of the package: it cannot rollback when it fails to install to the bootmedia, and it doesn't crash and burn the update run either, so it will not be noticed if you are not reading the update run output.

Run dpkg-reconfigure on your grub2 variant, so that it asks for your boot devices. Ensure it is correct, and let it update the bootloader on disk. Watch to ensure no errors are reported (i.e. do it from the terminal, not some GUI). This will sync everything.

Examples:
dpkg-reconfigure grub-efi-amd64
dpkg-reconfigure grub-pc

The other issue was a chain loader breackage on EFI, already fixed in the current packages.

A long list of GRUB2 secure-boot holes

Posted Aug 1, 2020 19:13 UTC (Sat) by suckfish (guest, #69919) [Link] (1 responses)

Re:

> UEFI Revocation List is updated on a system

How many items can that list accomodate and what happens when it overflows?

Given the state of its code, dribbling out grub2 vulnerabilities slowly appears to be a plausible attack here....

A long list of GRUB2 secure-boot holes

Posted Aug 7, 2020 22:37 UTC (Fri) by xnox (guest, #63320) [Link]

Some laptops will fail to apply the new dbxupdate as it is too large. Most likely it will gracefully reject it. In some cases it might brick and stop booting. But mostly it should be fine.


Copyright © 2020, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds