Secure Boot with Microsoft key isn’t worthwhile. References:
Complexities and security concerns of Secure Boot in the context of Linux distributions. The challenges posed by Secure Boot's requirement for a single signature on binaries, the reliance on Microsoft's key for booting, and the implications for user...
Less worthwhile with leaked Microsoft secure boot key.
Secure Boot brings shim into the mix, which is also not great… →
opened 02:15PM - 11 Feb 24 UTC
closed 07:02PM - 14 Feb 24 UTC
**short summary:**
Please remove shim HTTP boot due to potential future secur… ity issues and because it does not belong into shim.
**long reasoning:**
[CVE-2023-40547](https://thehackernews.com/2024/02/critical-bootloader-vulnerability-in.html) 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](https://github.com/rhboot/shim/commit/3d79bcb2651b9eae809b975b3e03e2f96c067072) and then [building got enabled by default without rationale](https://github.com/rhboot/shim/commit/9b0c281db4ca94ef4299911bd966eac8f75877f2).
**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.
Without full Verified Boot , without Sovereign Boot , it’s not worthwhile.
nurmagoz:
TPM
TPM for? Verified boot / Measured Boot ? Not needed until implemented.
nurmagoz:
microcode updates
There are no microcode updates for VMs.
Note: This forum thread is in the Whonix forums. So the only place where Whonix - as long as runs “primarily” inside VMs (ignoring physical isolation) - could flip the BIOS vs EFI setting is on the virtualizer settings level. And for that - at the time of writing - no sufficient rationale exists.
Whonix doesn’t run on hardware yet until Whonix-Host Operating System Live ISO, Whonix-Host Installer is available.
Even if Whonix-Host existed, the decision of BIOS or EFI depends on the host hardware. It’s not something that can be adjusted from within Whonix source code level. Modern hardware comes with EFI by default anyhow and does not even have BIOS compatibility module. So your EFI-only feature request on modern hardware is automatically fullfilled without any changes by Whonix required.
2 Likes