remove shim HTTP boot due to security issues

[adrelanos]

short summary:

Please remove shim HTTP boot due to potential future security issues and because it does not belong into shim.

long reasoning:

CVE-2023-40547 had a high CVE score, 9.8 of 10. From my perspective as a user, shim's HTTP boot feature is,

• highly surprising,
• seems highly unnecessary,
• seems to be not used much. [1]
• It's against unix philosophy.

Write programs that do one thing and do it well.

It's also against what shim says about itself in its own readme, quote:

shim is a trivial EFI application that, when run, attempts to open and execute another application. It will initially attempt to do this via the standard EFI LoadImage() and StartImage() calls. If these fail (because Secure Boot is enabled and the binary is not signed with an appropriate key, for instance) it will then validate the binary against a built-in certificate. If this succeeds and if the binary or signing key are not forbidden then shim will relocate and execute the binary.

HTTP boot does not seem simple at all and it's not as seen by the recent CVE.

Why would HTTP boot be integrated into shim itself? Wouldn't that be much more useful if implemented as an additional, optional EFI executable?

Why would shim re-implement networking, HTTP? Why would need to become almost it's own full operating system? GNU GRUB already has network boot functionality. So has the initramfs generator dracut. Why would this be needed also in shim?

shim HTTP boot was introduced without much of a rationale and then building got enabled by default without rationale.

high security impact:

I am not using HTTP boot, doesn't matter? No, not really. This is not only exploitable by those few using HTTP boot. Local exploitation is also possible.

Quote https://eclypsium.com/blog/the-real-shim-shady-how-cve-2023-40547-impacts-most-linux-systems/

The vulnerability can also be exploited locally by an attacker with enough privileges to manipulate data in the EFI Variables or on the EFI partition. This can be accomplished with a live Linux USB stick. The boot order can then be changed such that a remote and vulnerable shim is loaded on the system. This shim is then used to execute privileged code from the same remote server, all without ever disabling Secure Boot.

change request:

Therefore, could you please,

• A) preferably completely remove the HTTP boot feature? Or,
• B) If not removed, please at least disable building HTTP boot by default (as it was in the past). Or,
• C) disable the feature by default.

documentation request:

In case HTTP boot is not removed, please at least document the feature.

related source code file:

https://github.com/rhboot/shim/blob/main/httpboot.c

---

[1] I performed a web search and barely found anyone talking about using shim HTTP boot let alone how to do that.

[julian-klode]

Your methodology of searching for shim http boot is flawed... HTTP boot is a standard feature in EFI Firmware and widely used for mass deployment of entire fleets of machines. It replaces tftp which was used with PXE boot and notoriously unreliable and hard to set up.

It's funny you mention grub having network boot, because sure it has, but you also have to load the remote grub from the http server first...

[adrelanos]

Your methodology of searching for shim http boot is flawed... HTTP boot is a standard feature in EFI Firmware and widely used for mass deployment of entire fleets of machines. It replaces tftp which was used with PXE boot and notoriously unreliable and hard to set up.

Ok. But does this functionality belong into shim as I made the point above it actually does not? Seems more suitable somewhere outside of shim such as in GRUB (or some other bootloader) module.

It's funny you mention grub having network boot, because sure it has, but you also have to load the remote grub from the http server first...

One would need to have GRUB somewhere on some local drive, sure. But the same goes for shim. Therefore I don't see why this functionality should be in shim. Unless shim is part of the firmware (as far as I know it is not), both shim and GRUB are normal files on some local drive.

[julian-klode]

You misunderstand, your firmware has UEFI http boot entry that fetches the shim from the remote http server, then the shim needs to fetch the grub from the same server.

Needed for netbooting thin clients or doing deployment of enterprise hardware from a central deployment server.

[adrelanos]

UEFI HTTP boot is in the UEFI specification, true, but does this mean that shim must necessarily support it?

Would Microsoft would oppose a shim without HTTP boot support?

You misunderstand, your firmware has UEFI http boot entry that fetches the shim from the remote http server,

Got it. So those that need that, could use shim-http-boot and point to a shim that supports HTTP boot. Everyone else could use shim-trivial.

So I would suggest have two different versions of shim.

• A) shim-http-boot, and
• B) shim-trivial.

[Foxboron]

That requires multiple shims to be signed, that is probably not going to happen.

[miray-tf]

Signing two shims would not make any difference:

The http-code handling in Shim is only active if Shim itself was loaded through http. To exploit the vulnerability an attacker must be able to modify data that shim receives. But in that case the he can also replace the shim that was booted in the first place. So the attacker could always send any vulnerable shim he likes.

[adrelanos]

Signing two shims would not make any difference:

The http-code handling in Shim is only active if Shim itself was loaded through http. To exploit the vulnerability an attacker must be able to modify data that shim receives. But in that case the he can also replace the shim that was booted in the first place. So the attacker could always send any vulnerable shim he likes.

Quote myself from original post here.

I am not using HTTP boot, doesn't matter? No, not really. This is not only exploitable by those few using HTTP boot. Local exploitation is also possible.

Quote https://eclypsium.com/blog/the-real-shim-shady-how-cve-2023-40547-impacts-most-linux-systems/

The vulnerability can also be exploited locally by an attacker with enough privileges to manipulate data in the EFI Variables or on the EFI partition. This can be accomplished with a live Linux USB stick. The boot order can then be changed such that a remote and vulnerable shim is loaded on the system. This shim is then used to execute privileged code from the same remote server, all without ever disabling Secure Boot.

If the attacker modified EFI Variables or on the EFI partition then users would also have been vulnerable. This includes users not using HTTP boot, unless I am reading that wrong.

[Foxboron]

The http-code handling in Shim is only active if Shim itself was loaded through http.

I'm fairly sure this isn't correct? There is no check for IPXE booting or other things in the code paths for this.

[Foxboron]

If the attacker modified EFI Variables or on the EFI partition then users would also have been vulnerable. This includes users not using HTTP boot, unless I am reading that wrong.

You would need to pass a DeviceHandle that constructs an URL. This is commonly done in grub.cfg through the linuxefi call. But recently everything is built into the grub.efi binary, and signed, so you can't force a HTTP lookup if it's not already configured by the host.

Alternatively is that you find a signed grub.efi by a vendor that does this HTTP boot thing, then MITM the connection string and somehow get code exec?

It's unclear how easily exploitable this actually is if you can't modify the grub.cfg nor the grub.efi binary.

[julian-klode]

You should be able to construct a boot entry with a local shim and the second stage as a full http device path, no?

Anyway it's all pretty pointless to secure a local shim anyhow: You can just as easily create the boot entry that loads a vulnerable remote shim.

And almost everyone wants this feature so there's plenty of them.

Related, even if you disable it, you will still end up being revoked by http cves as they'll cause the sbat level to increase.

I'll close this as we all agreed in the cabal that the behaviour is the right one, and everyone was already enabling it anyway when it was not enabled by default, so you can see how popular it is!