A long list of GRUB2 secure-boot holes
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
Posted Jul 29, 2020 23:16 UTC (Wed)
by xnox (guest, #63320)
[Link] (3 responses)
Posted Jul 30, 2020 3:22 UTC (Thu)
by smitty_one_each (subscriber, #28989)
[Link]
Posted Jul 30, 2020 3:03 UTC (Thu)
by floppus (guest, #137245)
[Link] (1 responses)
The filesystem bugs sound serious, though.
Posted Jul 30, 2020 9:17 UTC (Thu)
by grawity (subscriber, #80596)
[Link]
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.
Posted Jul 30, 2020 14:03 UTC (Thu)
by Yenya (subscriber, #52846)
[Link] (2 responses)
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. Posted Jul 30, 2020 14:13 UTC (Thu)
by kevincox (guest, #93938)
[Link] (3 responses)
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.
Posted Jul 30, 2020 15:07 UTC (Thu)
by excors (subscriber, #95769)
[Link] (1 responses)
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.)
Posted Jul 30, 2020 16:36 UTC (Thu)
by Lennie (subscriber, #49641)
[Link]
https://www.linux-magazine.com/Issues/2018/206/Trusted-Pl...
Posted Aug 7, 2020 22:34 UTC (Fri)
by xnox (guest, #63320)
[Link]
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.
Posted Jul 30, 2020 15:02 UTC (Thu)
by dowdle (subscriber, #659)
[Link]
Posted Jul 30, 2020 22:19 UTC (Thu)
by jschrod (subscriber, #1646)
[Link] (2 responses)
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,
Posted Jul 31, 2020 14:22 UTC (Fri)
by amacater (subscriber, #790)
[Link] (1 responses)
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.
Posted Aug 2, 2020 18:00 UTC (Sun)
by hmh (subscriber, #3838)
[Link]
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:
The other issue was a chain loader breackage on EFI, already fixed in the current packages.
Posted Aug 1, 2020 19:13 UTC (Sat)
by suckfish (guest, #69919)
[Link] (1 responses)
> 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....
Posted Aug 7, 2020 22:37 UTC (Fri)
by xnox (guest, #63320)
[Link]
A long list of GRUB2 secure-boot holes
A long list of GRUB2 secure-boot holes
A long list of GRUB2 secure-boot holes
A long list of GRUB2 secure-boot holes
A long list of GRUB2 secure-boot holes
A long list of GRUB2 secure-boot holes
A long list of GRUB2 secure-boot holes
A long list of GRUB2 secure-boot holes
A long list of GRUB2 secure-boot holes
A long list of GRUB2 secure-boot holes
A long list of GRUB2 secure-boot holes
Joachim
A long list of GRUB2 secure-boot holes
A long list of GRUB2 secure-boot holes
dpkg-reconfigure grub-efi-amd64
dpkg-reconfigure grub-pc
A long list of GRUB2 secure-boot holes
A long list of GRUB2 secure-boot holes