[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <C76592F6-5353-4C8C-9263-E911D7020BA6@oracle.com>
Date: Thu, 30 Jul 2020 13:23:47 +0100
From: John Haxby <john.haxby@...cle.com>
To: oss-security@...ts.openwall.com
Subject: Re: UEFI SecureBoot bypass fixes rolled out to kernels
below radar
> On 30 Jul 2020, at 12:48, Jason A. Donenfeld <Jason@...c4.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
>
>
Download attachment "signature.asc" of type "application/pgp-signature" (269 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
