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

[Turritopsis Dohrnii Teo En Ming]

Again too difficult for me to understand.

Regards,

Mr. Turritopsis Dohrnii Teo En Ming
Targeted Individual in Singapore

On Wednesday, February 14th, 2024 at 12:53 AM, Jibun no Kage . 
<jibunnokage@gmail.com> wrote:

> 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