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

Mon Aug 3 02:03:08 PDT 2020

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.
>
>
> _______________________________________________
> conspire mailing list
> conspire at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/conspire
>
> _______________________________________________
> conspire mailing list
> conspire at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/conspire
> _______________________________________________
> conspire mailing list
> conspire at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/conspire
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linuxmafia.com/pipermail/conspire/attachments/20200803/9de70493/attachment.html>