CVE-2023-40547 – avoid incorrectly trusting HTTP headers

Vulnerability and context

• Bug is in shim’s HTTP boot code: it allocates a buffer based on the Content-Length header but copies based on the actual received body length, allowing an out‑of‑bounds write if the header lies.
• This exists in shim builds that include HTTP boot support; shim is mainly used as a Microsoft‑signed Secure Boot loader that then enforces its own policy via Machine Owner Keys (MOK).
• Earlier headlines implying “every Linux bootloader” were corrected: it’s a shim bug, introduced ~8 years ago.

Attack surface and severity

• Not limited to explicit HTTP boot:
  • Local: privileged malware can overwrite the EFI System Partition or EFI variables and force HTTP boot or chain shim→GRUB2→shim over HTTP.
  • Adjacent network: PXE boot plus MITM can be chained into HTTP shim loading.
  • Remote: MITM on HTTP boot against a victim using HTTP boot.
• Some argue that once an attacker can modify EFI vars/ESP, other attacks (e.g., adding MOKs, using older signed binaries) are already possible; others counter that Secure Boot’s goal is precisely to withstand such tampering.
• Disagreement over “Critical” rating: some see it as essential defense‑in‑depth, others think it’s less meaningful if the server or local system is already heavily compromised.

HTTP vs HTTPS and implementation details

• HTTPS does not prevent malicious servers; it mainly stops MITM.
• Several commenters note that UEFI/boot code may skip proper HTTPS certificate validation (CA store size, update and revocation complexities, time skew), making MITM realistic even over HTTPS.
• Debate over HTTP semantics: in HTTP/1.1, Content-Length is supposed to be authoritative; if an implementation instead trusts a separate “bodyLength” measurement, both must be reconciled carefully—this mismatch led to the bug.

Shim, Secure Boot, MOK, and revocation

• Typical usage is shim → GRUB → kernel on local disk; HTTP boot is niche but present.
• Shim verifies the next-stage binary against its own MOK list; Secure Boot revocation via UEFI DBX can invalidate vulnerable shim binaries, but many systems likely never update DBX.
• Measured boot and TPM can, in principle, bind disk decryption keys to specific boot components, but this is seen as complex and rarely used by typical users.

GPLv3, anti‑tivoization, and Microsoft’s signing policy

• Large subthread on why Microsoft avoids signing GPLv3 bootloaders like GRUB:
  • GPLv3’s “Installation Information” clause is cited: distributors of devices with GPLv3 components must provide whatever methods/authorization keys are needed for users to install and run modified versions on that device.
  • Some initially doubt this applies to signing keys, then concede that the language (“authorization keys”) plus FSF commentary about anti‑tivoization supports that interpretation.
  • Others argue that letting users enroll their own keys (rather than providing vendor private keys) should satisfy the license, and note that poor Secure Boot implementations that block user keys are the real problem.
  • There’s debate over whether signatures are copyright‑relevant at all, and whether merely signing a binary (without distributing it) can trigger GPL obligations; views conflict, and the legal status remains described as uncertain.
• Shim is MIT‑licensed to sidestep GPLv3 constraints, allowing it to be signed by Microsoft while enforcing its own trust policy (MOK).

Views on Secure Boot and ecosystem

• Some see Secure Boot as valid defense‑in‑depth, especially against “evil maid” attacks on unencrypted ESPs, and argue that vendors should allow user control over keys.
• Others are sharply critical:
  • Claim Secure Boot primarily entrenches vendor control (especially Microsoft’s default key) and resembles DRM more than user security.
  • Cite devices where Secure Boot can’t be disabled or user keys can’t be added, and where enabling Secure Boot causes usability issues (e.g., hibernation, “scary” warnings, Linux friction).
  • Worry about the PC platform trending toward a walled garden, likening it to earlier antitrust issues.

Network boot and design choices

• HTTP/PXE boot are described by several as “security nightmares” or at least highly risky, though others note they’re useful for lab testing and provisioning.
• Some question why shim directly implements HTTP boot at all instead of delegating to a separate, MOK‑signed EFI binary.
• There is criticism that such an obvious header‑trust bug should not have passed code review, with comments likening it to a beginner mistake, and side remarks on minor cleanups (e.g., typo fixes) in the patch.