Re: Critical Boot Loader Vulnerability in Shim Impacts Nearly All Linux Distros

[Jibun no Kage .]

In short, this has been a known issue, risk, at least in my world, since 
PXE was first developed and later adopted, supported.

Even with use of HTTPS as bulk transport handled off from PXE, so TFTP 
or other protocols are not used, such as NFS, SMB, etc.  There is real 
risk in context, as noted in the previous communication.

As someone that worked enterprise infrastructure engineering and design 
for about 30 years, any use of PXE is by definition, insecure.  This 
does not mean it cannot be used, but it has to be used with explicit 
understanding and restrictions.

For example, once a system is deployed and completely separate 
validation process must be used to ensure the system is safe, clean and 
secure.  This is a post installation audit and review automation/manual 
approval process.  This is above and beyond any boot protection such as 
TPM, etc., validation.

Moreover, PXE must only be used on secure segmented networking, and how 
that is done is completely driven by the organization security policy 
and goals.  For example, all sources used in PXE deployment must be 
signed, secured and validated before use, before published to private 
restricted repos.  That the physical and logical network is controlled 
and validated, again for any unknown clients or devices, or even 
traffic, so key IPS policy and procedure required.

In short, if you have any type of man-in-middle visibility, internally, 
your deployment use of PXE is really suspect.  Yes, you have to guard 
against internal bad-actors.  This why for say type-1 hypervisors, an 
'administrative' network is only used for deployment and updates, locked 
down to key repos, access gateways, and only via key personnel, etc., as 
well as direct management of the system over time, completely separate 
from any 'data' transport.

You never expose your administrative network in any way to any DMZ or 
external visibility, that would be, in a word, insane.  You never expose 
the administrative network to the greater intra-net of an organization, 
it fact, it should be considered a secure zone within the already 
secured zone of the intra-net behind the external firewalls.  And, yes, 
we used internal firewalls, as layers of defense, like secured air-locks 
or water-tight doors in concept across the intra-net of the 
organization, isolation was down to the physical layer in many cases, 
not just the virtual or logical layers.  Rings with in rings is a common 
model of firewall defense.

With all the above said, PXE use in any way is always a risk, and that 
risk must be well understood before accepted.

-JnK

On 2/9/2024 1:36 AM, Frantisek Rysanek wrote:
> > Article: Critical Boot Loader Vulnerability in Shim Impacts Nearly All Linux 
> > Distros
> > Link: 
> > https://thehackernews.com/2024/02/critical-bootloader-vulnerability-in.html
> >
> > May I know if Shim is an important component of GNU Grub?
> This is what the Shim does:
> https://github.com/rhboot/shim#shim-a-first-stage-uefi-bootloader
>
> Disclaimer: I am no expert on Grub or Shim or security.
> So my superficial reading of the message is:
>
> If you happen to netboot (PXEboot) using HTTP to transport your
> kernel+initrd,
> AND you have SecureBoot enabled, meaning that you rely on it for
> security,
> AND you're therefore using the Shim, to sign on the fly your kernel
> or whatever binaries you need to chainload off the LAN,
> ... THEN you are susceptible to the CVE, where the attacker (pulling
> off a MITM) can meticulously craft a binary payload, knowing the
> inner workings of the Shim, to execute his own arbitrary code, as
> part of the Shim.
>
> Color me illterate... isn't the assumed background scenario
> 1) rare
> 2) offering other, much simpler ways of attack, once you're in the
> MITM position, such as providing your own kernel and initrd,
> effectively booting your own OS in the first place?
>
> If you have someone capable of a MITM inside your LAN, don't you have
> a much more serious problem in the first place?
>
> I am no expert on this scenario, and I feel judgemental in my
> possibly unfounded opinion. Corrections are welcome.
>
> If I understand this correctly:
>
> - Linux distroes booting from local disk, in legacy or UEFI mode,
> UEFI with or without SecureBoot, are not affected
>
> - machines PXE-booting without SecureBoot (in legacy or UEFI mode)
> are not affected
>
> Except that booting without SecureBoot especially over the network
> maybe offers other, more serious vectors of attack.
>
> Overall, somehow I don't see anybody panic.
>
> Side note: I am not exactly sure, if this is specific to Grub. Grub
> indeed seems capable of PXE-booting with UEFI support, and uses the
> Shim in disk-based UEFI boot first and foremost. Not sure if iPXE is
> also affected. I don't know if the Shim including the CVE is present
> in iPXE, or can be combined with iPXE explicitly.
>
> Frank