CVE-2023-40547 – avoid incorrectly trusting HTTP headers

Re:CVE-2023-40547 – avoid incorrectly trusting HTTP headers by eurleif on Thursday January 25, 2024 @02:25PM (#39133877)

I'm curious how shim avoids the issue Microsoft is concerned about. Presumably if the anti-Tivoization clause of GPLv3 would require a Secure Boot signing key to be provided on request, it also requires a MOK signing key to be provided on request. The net result, then, seems to be that any arbitrary party can obtain signing keys which allow them to sign arbitrary code which will be booted (indirectly) via Secure Boot. How is that a meaningfully different outcome from the one we would have if Microsoft simply issued signing keys for GPLv3 projects like grub?

[ Parent | on HN ]

Re:CVE-2023-40547 – avoid incorrectly trusting HTTP headers by Arnavion on Thursday January 25, 2024 @02:28PM (#39133940)

MS doesn't "issue" signing keys. MS has a signing key that it uses to sign bootloaders, and which is the default key in every UEFI that wants to be able to boot Windows with Secure Boot enabled. (*)

Their argument is that if they signed a particular distro's GPL-licensed binary, then the user of that binary can ask for the source to be able to regenerate that binary, and that would require the signing key for completeness to be able to boot that binary.

shim is MIT-licensed so that requirement does not apply.

(*) To be precise, the key used to sign Windows and the key used to sign the rest are different, but both are enabled by default. That said, in 2022 there was talk about some UEFIs disabling that latter key by default: https://news.ycombinator.com/item?id=32066919

[ Parent | on HN ]

Re:CVE-2023-40547 – avoid incorrectly trusting HTTP headers by cesarb on Thursday January 25, 2024 @02:54PM (#39134300)

> I'm curious how shim avoids the issue Microsoft is concerned about.

IIRC, shim has a way to allow someone physically present to add additional keys which will also by trusted by that instance of shim. That's enough to satisfy the GPL requirements.

[ Parent | on HN ]

Re:CVE-2023-40547 – avoid incorrectly trusting HTTP headers by Arnavion on Thursday January 25, 2024 @02:59PM (#39134369)

Yes, that is how the MOK enrolment process works. The distro drops its MOK (the one it used to sign the kernel into the distro kernel package) into the ESP. On next boot shim notices the new key and asks the user if they want to enroll it. Similarly if the user wants to enroll additional keys for kernel modules they built themselves or got from somewhere else, they can do the same process.

[ Parent | on HN ]