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

[Rick Moen]

----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----

Date: Wed, 29 Jul 2020 18:46:43 -0700
From: Rick Moen <rick at linuxmafia.com>
To: felton-lug at googlegroups.com
Subject: Re: [Felton LUG] Oh boy, this doesn't look good...
Organization: If you lived here, you'd be $HOME already.

Quoting Wayne (Wayne at TradeTimer.com):

> https://www.bleepingcomputer.com/news/security/boothole-grub-bootloader-bug-lets-hackers-hide-malware-in-linux-windows/

Whenever I see there's a news or analysis item about Linux security at
any popular-news IT site, including at a popular-news infosec site like
BleepingComputer.com, I expect the news item to be misleading (if not
mistaken in places).  

This particular news item seems to be basically correct, but arguably
maybe a little misleading, depending on how one parses it.  Summary:


GRUB2 is intended to implement & enforce SecureBoot on a system,
if/where so configured.  But there's an (arguable) weakness, in that
GRUB2 follows directives the superuser places into grub.cfg:  Modifying
grub.cfg requires root privilege, but the news item's point is that a
fully bulletproof SecureBoot configuration should by design be
untouchable by the root user.

So, a bad actor or code running under the direction of a bad actor on a
Linux system (yclept 'malware') could alter the system's boot
configuration, because that is, by traditional Unix system design, a
privilege of the root user.  Changing this overall situation would
require some sort of modification to standard GRUB2 to make it check a
crypto signature on grub.cfg and refuse to process it during bootup if
the signature doesn't check out.  As it does not, at present.

The fact that the local root user can edit the contents of grub.cfg and
GRUB2 will (thereupon) still regard it as valid is being named the
'BootHole vulnerability' by security firm Eclypsium.


So, news flash:  Root can still do root things.  

To the extent that one is of the opinion that Secure Boot should
crypto-validate every aspect of bootup, this is a problem to be solved.

Personally, I don't use SecureBoot, so the scope of its coverage doesn't
especially matter to me.  But Views Differ[tm].


----- End forwarded message -----