[conspire] (forw) Re: [Felton LUG] Oh boy, this doesn't look good...

Mon Aug 3 21:57:21 PDT 2020

A pretty good write-up/summary.  :-)  Thanks.

A few points/corrections I'd add:

As far as EFI & secure boot, it's not necessarily GRUB (GRUB2)
that's signed.  In some(/many?) of the GRUB cases, the OS
uses a signed shim, which in turn does its own verification of
GRUB, e.g.:
"Due to the way that Debian's Secure Boot key management works, Debian  
does not need to revoke its existing Microsoft-signed shim packages.  
However, the signed versions of the shim-helper packages needed  
rebuilding to use the new signing key"
https://www.debian.org/security/2020-GRUB-UEFI-SecureBoot/
So, e.g., in some cases, the OS provider/distro uses a shim,
which is EFI & secure boot validated, then the shim
(presumably) verifies GRUB (or what have you).

Also, this bit caught my eye:
"With the sole exception of one bootable tool vendor who added custom  
code to perform a signature verification of the grub.cfg config file  
in addition to the signature verification performed on the GRUB2  
executable, all versions of GRUB2 that load commands from an external  
grub.cfg configuration file are vulnerable."
https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/
So ... I wonder which vendor did it that way, and if that bit
is Open Source ... and might be usefully leveraged by others.

> From: "tom r lopes" <tomrlopes at gmail.com>
> Subject: Re: (forw) Re: [Felton LUG] Oh boy, this doesn't look good...
> Date: Mon, 3 Aug 2020 02:03:08 -0700

> Write up on the "boot hole" here:
> https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/
>
> Correct me if I'm wrong  -- my understanding:
>
> Secure boot tries to verify the code before it allows it to run and to do
> this it checks
> the signatures with keys provided by Microsoft.  The idea is to make sure
> the kernel
> hasn't been tampered with.  Something like a rootkit which would be hard to
> detect
> from within the OS.
>
> This problem is with Grub2.  But the Grub binary is not modified at all.
> So secure boot
> will load and run grub on a compromised system.  Grub is attacked here by
> modifying
> its input, the grub.cfg file.  grub.cfg is just a text file but the
> researchers found that if you
> make it too big it would cause a buffer overrun in Grub.  And maybe run
> some extra code.
> grub.cfg can't really be verified (signed) because it has the list of your
> OS's and the names you give them and the UUID's and all that.  Too many
> variations.
>
> So they will go and patch grub.  Then have to get the new grub signed so
> that secure boot
> will allow it.  Then they will revoke the key for the old grub.  If you
> happen to be running
> secure boot and neglect to update grub code before the revocation, your
> machine will
> fail to boot.
>
> Thomas
>
>
>> ---------- Forwarded message ----------
>> From: Tony Godshall <tony at of.net>
>> To: Michael Paoli <Michael.Paoli at cal.berkeley.edu>
>> Cc: conspire at linuxmafia.com
>> Bcc:
>> Date: Sat, 1 Aug 2020 15:09:55 -0700
>> Subject: Re: [conspire] (forw) Re: [Felton LUG] Oh boy, this doesn't look
>> good...
>> Protecting from people with physical access to the device is... something
>> very few people care much about except vendors who want to keep you from
>> accessing you own device. Hell, the whole existence of signed bootloaders
>> make just complicates our lives.
>>
>> On Sat, Aug 1, 2020, 1:42 AM Michael Paoli <Michael.Paoli at cal.berkeley.edu>
>> wrote:
>>
>>> Yep, even calling that GRUB2 "boothole" bug a security bug is a fair
>>> bit of a stretch, ... but yeah, sure, security bug.  How so?
>>> Might have to set up relatively contrived circumstances, but yes.
>>> E.g. set up sudo access to give non-root user access to
>>> very selectively edit the grub boot configuration file.
>>> But let's say it's a less than perfect implementation of
>>> least privilege principle.  Does fair bit of sanity check
>>> and say, only lets the person edit one field on one line ...
>>> and, say, that field is pretty well checked ... must start and
>>> end with ", can't contain " or newline within.  A semi-reasonable
>>> check.  But, alas, GRUB2 ... and somebody didn't check - and maybe
>>> in such a sudo capability too - for things that are too or unreasonably
>>> long.  And ... GRUB2 has a buffer overflow exploit in its
>>> handling/parsing of the file.  "Oops".
>>> So, anyway, with our contrivance, taking such together, yes, a
>>> security bug.  Now, how many hundreds of thousands or millions or
>>> more such systems have such a configuration with sudo or the
>>> like that makes that a privilege escalation attack?  Probably
>>> very few.  So ... not much of an issue.  But yes, still (barely) a
>>> security bug ... why?  Because it's something that normally operates
>>> with privilege, and is not doing so as designed/intended ... so ...
>>> that's enough to qualify it as a security bug.  But "severe"? Not
>>> even close.
>>>
>>> > From: "Rick Moen" <rick at linuxmafia.com>
>>> > Subject: Re: [conspire] (forw) Re: [Felton LUG] Oh boy, this doesn't
>>> > look good...
>>> > Date: Thu, 30 Jul 2020 03:47:33 -0700
>>>
>>> > Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):
>>> >
>>> >> "severe vulnerability exists in almost all signed versions of GRUB2
>>> >> bootloader"
>>> >> <cough, cough>
>>> >> Bug, sure.  Even a security bug.  But severe?  Come now.
>>> >> So, how many hundreds of thousands, or millions or more,
>>> >> computers have been taken over by bad actors by this
>>> >> "severe" vulnerability.  Oh, a few research computers in a security
>>> >> research lab ...
>>> >> where the researchers were given unrestricted root access on these
>>> >> hosts?  Uh huh.  Tell me again about how "severe" this
>>> >> vulnerability is.
>>> >
>>> > In fact, as with many security news stories in popular-news IP magazines
>>> > and Web sites, they glossed over the fact that this alleged
>>> > vulnerability ('BootHole') doesn't permit any host compromise at all.
>>> > Using it to 'load arbitrary code' requires already being in full control
>>> > of the machine in the first place.  It's only a problem if you seriously
>>> > expect local root users to be kept out of the boot chain.  Which from a
>>> > Unix-ey perspective is a pretty bizarre use-case.
>>> >
>>> > But popular-news IT sources mostly cater to readers who are not used to
>>> > thinking about security, and are ripe for clickbait.
>>> >
>>> >
>>> >> You want severe?  How 'bout something like this:
>>> >> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-5902
>>> >> https://www.kb.cert.org/vuls/id/290915
>>> >
>>> > Yeah, 'unauthenticated remote command execution': those are bad words.
>>>
>>>
>>> _______________________________________________
>>> conspire mailing list
>>> conspire at linuxmafia.com
>>> http://linuxmafia.com/mailman/listinfo/conspire
>>>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: "paulz at ieee.org" <paulz at ieee.org>
>> To: Michael Paoli <michael.paoli at cal.berkeley.edu>, Tony Godshall <
>> tony at of.net>
>> Cc: conspire at linuxmafia.com
>> Bcc:
>> Date: Mon, 3 Aug 2020 06:36:06 +0000 (UTC)
>> Subject: Re: [conspire] (forw) Re: [Felton LUG] Oh boy, this doesn't look
>> good...
>> So, what is the threat that these measures are intended to thwart:
>>
>> Bad actors that might want to steal data or install ransomware?
>>
>> OR
>>
>> People with legitimate root access that threaten Microsoft's control?
>>
>> On Sunday, August 2, 2020, 9:33:40 PM PDT, Tony Godshall <tony at of.net>
>> wrote:
>>
>>
>> Protecting from people with physical access to the device is... something
>> very few people care much about except vendors who want to keep you from
>> accessing you own device. Hell, the whole existence of signed bootloaders
>> make just complicates our lives.
>>
>> On Sat, Aug 1, 2020, 1:42 AM Michael Paoli <Michael.Paoli at cal.berkeley.edu>
>> wrote:
>>
>> Yep, even calling that GRUB2 "boothole" bug a security bug is a fair
>> bit of a stretch, ... but yeah, sure, security bug.  How so?
>> Might have to set up relatively contrived circumstances, but yes.
>> E.g. set up sudo access to give non-root user access to
>> very selectively edit the grub boot configuration file.
>> But let's say it's a less than perfect implementation of
>> least privilege principle.  Does fair bit of sanity check
>> and say, only lets the person edit one field on one line ...
>> and, say, that field is pretty well checked ... must start and
>> end with ", can't contain " or newline within.  A semi-reasonable
>> check.  But, alas, GRUB2 ... and somebody didn't check - and maybe
>> in such a sudo capability too - for things that are too or unreasonably
>> long.  And ... GRUB2 has a buffer overflow exploit in its
>> handling/parsing of the file.  "Oops".
>> So, anyway, with our contrivance, taking such together, yes, a
>> security bug.  Now, how many hundreds of thousands or millions or
>> more such systems have such a configuration with sudo or the
>> like that makes that a privilege escalation attack?  Probably
>> very few.  So ... not much of an issue.  But yes, still (barely) a
>> security bug ... why?  Because it's something that normally operates
>> with privilege, and is not doing so as designed/intended ... so ...
>> that's enough to qualify it as a security bug.  But "severe"? Not
>> even close.
>>
>> > From: "Rick Moen" <rick at linuxmafia.com>
>> > Subject: Re: [conspire] (forw) Re: [Felton LUG] Oh boy, this doesn't
>> > look good...
>> > Date: Thu, 30 Jul 2020 03:47:33 -0700
>>
>> > Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):
>> >
>> >> "severe vulnerability exists in almost all signed versions of GRUB2
>> >> bootloader"
>> >> <cough, cough>
>> >> Bug, sure.  Even a security bug.  But severe?  Come now.
>> >> So, how many hundreds of thousands, or millions or more,
>> >> computers have been taken over by bad actors by this
>> >> "severe" vulnerability.  Oh, a few research computers in a security
>> >> research lab ...
>> >> where the researchers were given unrestricted root access on these
>> >> hosts?  Uh huh.  Tell me again about how "severe" this
>> >> vulnerability is.
>> >
>> > In fact, as with many security news stories in popular-news IP magazines
>> > and Web sites, they glossed over the fact that this alleged
>> > vulnerability ('BootHole') doesn't permit any host compromise at all.
>> > Using it to 'load arbitrary code' requires already being in full control
>> > of the machine in the first place.  It's only a problem if you seriously
>> > expect local root users to be kept out of the boot chain.  Which from a
>> > Unix-ey perspective is a pretty bizarre use-case.
>> >
>> > But popular-news IT sources mostly cater to readers who are not used to
>> > thinking about security, and are ripe for clickbait.
>> >
>> >
>> >> You want severe?  How 'bout something like this:
>> >> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-5902
>> >> https://www.kb.cert.org/vuls/id/290915
>> >
>> > Yeah, 'unauthenticated remote command execution': those are bad words.