[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] UEFI SecureBoot bypass fixes rolled out to kernels below radar
From:       John Haxby <john.haxby () oracle ! com>
Date:       2020-07-30 12:23:47
Message-ID: C76592F6-5353-4C8C-9263-E911D7020BA6 () oracle ! com
[Download RAW message or body]

> On 30 Jul 2020, at 12:48, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> 
> Hi,
> 
> I thought I should mention that yesterday's UEFI SecureBoot bypass
> headlines neglected to mention the bugs I found over a month ago (with
> the exception of Debian's announcement, which got some details wrong
> initially but those have since been rectified).
> 
> It appears that Linux vendors are now releasing fixes for:
> 
> - CVE-2019-20908
> https://git.zx2c4.com/american-unsigned-language/tree/american-unsigned-language.sh
> https://www.openwall.com/lists/oss-security/2020/06/14/1
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-20908
> 
> - CVE-2020-15780
> https://git.zx2c4.com/american-unsigned-language/tree/american-unsigned-language-2.sh
> https://www.openwall.com/lists/oss-security/2020/06/15/3
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15780
> 
> In the Red Hat Enterprise Linux 8 kernel sources, diffing yesterday's
> release with the one from a few weeks prior, we see a patch for both of
> these, which I've put at the bottom of this email.
> 
> It seems like mention of these was left out from the advisories that
> were making news yesterday from Microsoft/Red Hat/etc, presumably
> because there's no shiny logo and press release route with these
> exploits, but rather just shoddy exploits and posted them here,
> alongside patches on LKML.

Yep.  I mentioned these in my post yesterday but I didn't go into any detail as they've been \
public for some little while.   The various vendor updates are patching both CVEs, as you \
noted.  Ubuntu punlished an advisory for these a few days ago \
(https://ubuntu.com/security/notices/USN-4440-1), we, and others, rolled the kernel fixes in \
with the rest of the changes.

Important and necessary as these fixes are they're not the main reason for pushing new kernels \
out along with updated grub and shim.   Complete mitigation requires updating the entire \
signature chain and most vendors needed to resign the kernel.  (I'm not only losing track of \
who resigned what, but the will to live :))

> 
> But anyway, PSA: if you're scrambling to get your systems updated for
> this, be sure to update your kernel in addition to GRUB2. This is more
> than just a bootloader situation. And I'm sure we'll have plenty more
> SecureBoot bypasses coming up too.


In other breaking news, software is buggy :)  As sure as it rains in Lancashire, there will be \
more secure boot bypass bugs somewhere along the chain.  And we will be ready for them.

Seriously, as I and others have said several times: you must update the entire signature chain \
then, and only then, you must update the dbx.    Someone, somewhere, probably several someones, \
are going to decide they know better and wind up bricking their secure boot systems.    \
Personally, they'll find my sympathy in short supply when they do :/

jch


> 
> Jason
> 
> 
> RHEL8 patch, which shipped yesterday:
> 
> diff -ru linux-4.18.0-193.13.2.el8_2/drivers/acpi/acpi_configfs.c \
>                 linux-4.18.0-193.14.3.el8_2/drivers/acpi/acpi_configfs.c
> --- linux-4.18.0-193.13.2.el8_2/drivers/acpi/acpi_configfs.c	2020-07-14 00:38:37.000000000 \
>                 +0200
> +++ linux-4.18.0-193.14.3.el8_2/drivers/acpi/acpi_configfs.c	2020-07-20 16:02:22.000000000 \
> +0200 @@ -14,6 +14,7 @@
> #include <linux/module.h>
> #include <linux/configfs.h>
> #include <linux/acpi.h>
> +#include <linux/kernel.h>
> 
> #include "acpica/accommon.h"
> #include "acpica/actables.h"
> @@ -31,7 +32,10 @@
> {
> 	const struct acpi_table_header *header = data;
> 	struct acpi_table *table;
> -	int ret;
> +	int ret = kernel_is_locked_down("Modifying ACPI tables");
> +
> +	if (ret)
> +		return ret;
> 
> 	table = container_of(cfg, struct acpi_table, cfg);
> 
> diff -ru linux-4.18.0-193.13.2.el8_2/drivers/firmware/efi/efi.c \
>                 linux-4.18.0-193.14.3.el8_2/drivers/firmware/efi/efi.c
> --- linux-4.18.0-193.13.2.el8_2/drivers/firmware/efi/efi.c	2020-07-14 00:38:37.000000000 \
>                 +0200
> +++ linux-4.18.0-193.14.3.el8_2/drivers/firmware/efi/efi.c	2020-07-20 16:02:22.000000000 \
> +0200 @@ -31,6 +31,7 @@
> #include <linux/acpi.h>
> #include <linux/ucs2_string.h>
> #include <linux/memblock.h>
> +#include <linux/kernel.h>
> 
> #include <asm/early_ioremap.h>
> 
> @@ -245,6 +246,11 @@
> static char efivar_ssdt[EFIVAR_SSDT_NAME_MAX] __initdata;
> static int __init efivar_ssdt_setup(char *str)
> {
> +	int ret = kernel_is_locked_down("Modifying ACPI tables");
> +
> +	if (ret)
> +		return ret;
> +
> 	if (strlen(str) < sizeof(efivar_ssdt))
> 		memcpy(efivar_ssdt, str, strlen(str));
> 	else
> 
> 


["signature.asc" (signature.asc)]

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iHUEAREIAB0WIQT+pxvb11CFWUkNSOVFC7t+lC+jyAUCXyK70wAKCRBFC7t+lC+j
yKAWAPsGBj8hFLc+sztz0+9qJx5ordXKL+jPFhTx1ekBAffGUgD/fRkrSp7XwWJZ
6vcktvPgke1g1RaKhqBY34kYJdb0CFA=
=qiwI
-----END PGP SIGNATURE-----


[prev in list] [next in list] [prev in thread] [next in thread]