Re: UEFI SecureBoot bypass fixes rolled out to kernels below radar

                							

                <!--X-Body-Begin-->
<!--X-User-Header-->

oss-sec
mailing list archives
<!--X-User-Header-End-->
<!--X-TopPNI-->

By Date

By Thread

</form>

<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
Re: UEFI SecureBoot bypass fixes rolled out to kernels below radar

<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->

From: John Haxby &lt;john.haxby () oracle com&gt;

Date: Thu, 30 Jul 2020 13:23:47 +0100

<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->

<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->

On 30 Jul 2020, at 12:48, Jason A. Donenfeld &lt;Jason () zx2c4 com&gt; 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 &lt;linux/module.h&gt;
#include &lt;linux/configfs.h&gt;
#include &lt;linux/acpi.h&gt;
+#include &lt;linux/kernel.h&gt;

#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 &lt;linux/acpi.h&gt;
#include &lt;linux/ucs2_string.h&gt;
#include &lt;linux/memblock.h&gt;
+#include &lt;linux/kernel.h&gt;

#include &lt;asm/early_ioremap.h&gt;

@@ -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) &lt; sizeof(efivar_ssdt))
              memcpy(efivar_ssdt, str, strlen(str));
      else

Attachment:
signature.asc
Description: Message signed with OpenPGP

<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->

<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->

By Date

By Thread

Current thread:

UEFI SecureBoot bypass fixes rolled out to kernels below radar Jason A. Donenfeld (Jul 30)

Re: UEFI SecureBoot bypass fixes rolled out to kernels below radar John Haxby (Jul 30)

<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->