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 . <jibunnok...@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
