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