10 ms·

shim is an EFI bootloader commonly used by Linux distros that want to enable Secure Boot. Distros want an easy path to enabling Secure Boot using the default pr

shim is an EFI bootloader commonly used by Linux distros that want to enable Secure Boot. Distros want an easy path to enabling Secure Boot using the default preloaded Microsoft signing key, rather than require users to enroll their own key. But Microsoft refuses to sign GPL bootloaders like grub in general, so shim was made to be able to be signed by the Microsoft key. (shim then implements its own separate signature verification of what it boots, based on a different key called the Machine Owner Key, MOK.) When you tell shim what EFI binary to boot, you can specify it as an HTTP URL. If you do this and the HTTP server is malicious, it can trigger an out-of-bounds write. However, usually you use it to boot a local second-stage bootloader like grub (hence the name "shim"), so it's unlikely to be a problem for most installs. Regardless, Secure Boot was built from the start to allow previously-signed binaries to be revoked via the DBX list - a list of signatures that can be loaded into the UEFI to make it reject binaries even if they have a valid signature. When (If) the signatures of old shim binaries with this bug are added to the list, you can update the list in your own machines. Updates may be distributed as capsule updates (via LVFS etc), or if you manage your SB keys and vars you can download and enroll the list from https://uefi.org/revocationlistfile https://uefi.org/revocationlistfile

Dalewyn 3y ago
>However, usually you use it to boot a local second-stage bootloader like grub (hence the name "shim") Would Windows Boot Manager not serve that purpose also? I have WBM chainloading into GRUB on one of my older BIOS machines, but I never got around to doing that on a UEFI machine so I'm not aware of any showstoppers.
- earthling8118 3y ago
  Windows is a showstopper itself. It might play nicely sometimes but it isn't a workable solution. I can no longer ever try dual booting because it doesn't respect anything but itself. It'll just decide to get rid of other bootloaders at its own discretion.
  - Dalewyn 3y ago
    I'm talking about dumping the subsequent bootloaders such as GRUB to a file located in a Windows-accessible location, and then adding a menu entry for Windows Boot Manager to chainload into it. As far as I know, Windows doesn't just overwrite the BCD like that unless you explicitly tell it to. Also, obviously the assumption is Windows isn't a showstopper such as in my case. I'm inquiring if there are any practical or technical concerns that would preclude using WBM as a shim.
rany_ 3y ago
> because MS refuses to sign GPL bootloaders like grub in general This is because MSFT lawyers think that if you sign a GPLv3 licensed bootloader like GRUB, you might have a right to compel the developer into handing over their signing keys. Source: https://techcommunity.microsoft.com/t5/hardware-dev-center/updated-uefi-signing-requirements/ba-p/1062916 https://techcommunity.microsoft.com/t5/hardware-dev-center/u...
- nailer 3y ago
  > FYI the reason is that the GPL would require you to hand over the signing keys. If you sign a GPLv3 licensed bootloader like GRUB, you're forced to also make public the signing key... which defeats the purpose. That seems to be a ridiculous interpretation of the GPL (no personal offense meant, I'm sure you're a fine person but this idea is genuinely very silly). Signatures on binaries are not part of the source code, and therefore the GPL isn't concerned with them. Think of: - every signed binary for an open source app on a Linux distro or Windows install - Every open source web app delivered over a TLS cert Nobody has ever considered that the private keys used to sign the package, executable or web site cert to be required by the GPL.
  - rany_ 3y ago
    > Code submitted for UEFI signing must not be subject to GPLv3 or any license that purports to give someone the right to demand authorization keys to be able to install modified forms of the code on a device. Code that is subject to such a license that has already been signed might have that signature revoked. For example, GRUB 2 is licensed under GPLv3 and will not be signed. It does according to MSFT lawyers: https://techcommunity.microsoft.com/t5/hardware-dev-center/updated-uefi-signing-requirements/ba-p/1062916 https://techcommunity.microsoft.com/t5/hardware-dev-center/u...
    - nailer 3y ago
      > any license that purports to give someone the right to demand authorization keys to be able to install modified forms of the code on a device There's nowhere in the GPLv3 that says that (then again, that sentence doesn't imply there is). Anyone can download and modify the grub source code, and compile it. It doesn't mean Microsoft is obliged to sign their fork. I wonder if there's something that confused (or was bad faith interpreted) by Microsoft's lawyers? Maybe someone can just use another open source license? Ie, anything not called 'GPLv3' which, like every other OSS license, does not purport to give someone the right to demand authorization keys to be able to install modified forms of the code on a device.
JohnFen 3y ago
> When you tell shim what EFI binary to boot, you can specify it as an HTTP URL. Thank you for explaining this. I was seriously curious as to why a boot loader would be doing any network communications at all.
- dharmab 3y ago
  As a junior IT person long ago we used remote image booting in our lab to quickly test new software builds on real hardware. Back then it involved janky TFTP.
  - fullspectrumdev 3y ago
    The horrors of PXE? Where you end up with a clusterfuck of DHCP and TFTP to load the correct image?
    - dharmab 3y ago
      Exactly!
eurleif 3y ago
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?
- Arnavion 3y ago
  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 https://news.ycombinator.com/item?id=32066919
- cesarb 3y ago
  > 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.
  - Arnavion 3y ago
    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.
RcouF1uZ4gsC 3y ago
> When you tell shim what EFI binary to boot, you can specify it as an HTTP URL. If you do this and the HTTP server is malicious, it can trigger an out-of-bounds write. Can a malicious server just send a compromised binary directly?
- smileybarry 3y ago
  No, because that binary is still sigchecked against the locally-accepted keys (MOK). But an out-of-bounds write can be abused to bypass that.
deleted 3y ago
[deleted]
BillDemirkapi 3y ago
OP/bug finder here with some clarifying information. It's a common misconception that this issue can only be abused if you use HTTP boot. That is not the case at all, otherwise it wouldn't be Critical. This bug can be abused locally (privileged malware can overwrite the EFI partition), from an adjacent network if PXE boot is enabled (w/ MiTM), or remotely if HTTP boot is used (w/ MiTM). More details on these scenarios: 1. A remote attacker with no privileges in a man-in-the-middle (MitM) position could leverage the issue against a victim machine that uses HTTP boot. No direct access to the victim machine is required. 2. A remote attacker with privileges and code execution on the victim machine could leverage the issue to bypass Secure Boot, even if the victim does not already use HTTP boot (as long as firmware has HTTP support). How? Several ways: - An attacker can edit the boot order variable to specify a controlled attacker server. - An attacker can chain shim->GRUB2->shim (via HTTP). For this technique, an attacker would overwrite the boot loader in the EFI partition to a legitimate shim and GRUB2 image. The attacker would create a grub.cfg that chainloads a new shim via HTTP. This is possible because GRUB2's device syntax allows you to specify any supported device, including HTTP (if available). 3. An adjacent attacker with no privileges in a man-in-the-middle (MitM) position could leverage the issue against a victim machine that uses PXE boot. PXE is separate from HTTP boot, but similar to the local vector, an attacker can chain together shim (via PXE)->GRUB2 (via PXE)->shim (via HTTP).
- Arnavion 3y ago
  Yes, if the attacker can edit the the victim machine's EFI vars or the contents of its ESP, then they can make the victim machine use HTTP boot even if the victim machine didn't use HTTP boot originally. However at that point they can also wreak more havoc without involving HTTP boot. For the case where the default configuration has been set up to just chainload grub (ie what distros use shim for), and where an attacker editing EFI vars / ESP is not in the threat model, there is no concern. Yes that is just "It's not a concern because you defined it to not be." but that is the reality for most users of Secure Boot on Linux. Also note that the reason I wrote that paragraph is because the HN submission was originally submitted with a title along the lines of "Every install of shim is affected".
  - 3y ago

Dalewyn 3y ago

>However, usually you use it to boot a local second-stage bootloader like grub (hence the name "shim") Would Windows Boot Manager not serve that purpose also? I have WBM chainloading into GRUB on one of my older BIOS machines, but I never got around to doing that on a UEFI machine so I'm not aware of any showstoppers.

earthling8118 3y ago
Windows is a showstopper itself. It might play nicely sometimes but it isn't a workable solution. I can no longer ever try dual booting because it doesn't respect anything but itself. It'll just decide to get rid of other bootloaders at its own discretion.
- Dalewyn 3y ago
  I'm talking about dumping the subsequent bootloaders such as GRUB to a file located in a Windows-accessible location, and then adding a menu entry for Windows Boot Manager to chainload into it. As far as I know, Windows doesn't just overwrite the BCD like that unless you explicitly tell it to. Also, obviously the assumption is Windows isn't a showstopper such as in my case. I'm inquiring if there are any practical or technical concerns that would preclude using WBM as a shim.

rany_ 3y ago

> because MS refuses to sign GPL bootloaders like grub in general This is because MSFT lawyers think that if you sign a GPLv3 licensed bootloader like GRUB, you might have a right to compel the developer into handing over their signing keys. Source: https://techcommunity.microsoft.com/t5/hardware-dev-center/updated-uefi-signing-requirements/ba-p/1062916 https://techcommunity.microsoft.com/t5/hardware-dev-center/u...

nailer 3y ago
> FYI the reason is that the GPL would require you to hand over the signing keys. If you sign a GPLv3 licensed bootloader like GRUB, you're forced to also make public the signing key... which defeats the purpose. That seems to be a ridiculous interpretation of the GPL (no personal offense meant, I'm sure you're a fine person but this idea is genuinely very silly). Signatures on binaries are not part of the source code, and therefore the GPL isn't concerned with them. Think of: - every signed binary for an open source app on a Linux distro or Windows install - Every open source web app delivered over a TLS cert Nobody has ever considered that the private keys used to sign the package, executable or web site cert to be required by the GPL.
- rany_ 3y ago
  > Code submitted for UEFI signing must not be subject to GPLv3 or any license that purports to give someone the right to demand authorization keys to be able to install modified forms of the code on a device. Code that is subject to such a license that has already been signed might have that signature revoked. For example, GRUB 2 is licensed under GPLv3 and will not be signed. It does according to MSFT lawyers: https://techcommunity.microsoft.com/t5/hardware-dev-center/updated-uefi-signing-requirements/ba-p/1062916 https://techcommunity.microsoft.com/t5/hardware-dev-center/u...
  - nailer 3y ago
    > any license that purports to give someone the right to demand authorization keys to be able to install modified forms of the code on a device There's nowhere in the GPLv3 that says that (then again, that sentence doesn't imply there is). Anyone can download and modify the grub source code, and compile it. It doesn't mean Microsoft is obliged to sign their fork. I wonder if there's something that confused (or was bad faith interpreted) by Microsoft's lawyers? Maybe someone can just use another open source license? Ie, anything not called 'GPLv3' which, like every other OSS license, does not purport to give someone the right to demand authorization keys to be able to install modified forms of the code on a device.

JohnFen 3y ago

> When you tell shim what EFI binary to boot, you can specify it as an HTTP URL. Thank you for explaining this. I was seriously curious as to why a boot loader would be doing any network communications at all.

dharmab 3y ago
As a junior IT person long ago we used remote image booting in our lab to quickly test new software builds on real hardware. Back then it involved janky TFTP.
- fullspectrumdev 3y ago
  The horrors of PXE? Where you end up with a clusterfuck of DHCP and TFTP to load the correct image?
  - dharmab 3y ago
    Exactly!

eurleif 3y ago

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?

Arnavion 3y ago
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 https://news.ycombinator.com/item?id=32066919
cesarb 3y ago
> 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.
- Arnavion 3y ago
  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.

RcouF1uZ4gsC 3y ago

> When you tell shim what EFI binary to boot, you can specify it as an HTTP URL. If you do this and the HTTP server is malicious, it can trigger an out-of-bounds write. Can a malicious server just send a compromised binary directly?

smileybarry 3y ago
No, because that binary is still sigchecked against the locally-accepted keys (MOK). But an out-of-bounds write can be abused to bypass that.

deleted 3y ago

[deleted]

BillDemirkapi 3y ago

OP/bug finder here with some clarifying information. It's a common misconception that this issue can only be abused if you use HTTP boot. That is not the case at all, otherwise it wouldn't be Critical. This bug can be abused locally (privileged malware can overwrite the EFI partition), from an adjacent network if PXE boot is enabled (w/ MiTM), or remotely if HTTP boot is used (w/ MiTM). More details on these scenarios: 1. A remote attacker with no privileges in a man-in-the-middle (MitM) position could leverage the issue against a victim machine that uses HTTP boot. No direct access to the victim machine is required. 2. A remote attacker with privileges and code execution on the victim machine could leverage the issue to bypass Secure Boot, even if the victim does not already use HTTP boot (as long as firmware has HTTP support). How? Several ways: - An attacker can edit the boot order variable to specify a controlled attacker server. - An attacker can chain shim->GRUB2->shim (via HTTP). For this technique, an attacker would overwrite the boot loader in the EFI partition to a legitimate shim and GRUB2 image. The attacker would create a grub.cfg that chainloads a new shim via HTTP. This is possible because GRUB2's device syntax allows you to specify any supported device, including HTTP (if available). 3. An adjacent attacker with no privileges in a man-in-the-middle (MitM) position could leverage the issue against a victim machine that uses PXE boot. PXE is separate from HTTP boot, but similar to the local vector, an attacker can chain together shim (via PXE)->GRUB2 (via PXE)->shim (via HTTP).

Arnavion 3y ago
Yes, if the attacker can edit the the victim machine's EFI vars or the contents of its ESP, then they can make the victim machine use HTTP boot even if the victim machine didn't use HTTP boot originally. However at that point they can also wreak more havoc without involving HTTP boot. For the case where the default configuration has been set up to just chainload grub (ie what distros use shim for), and where an attacker editing EFI vars / ESP is not in the threat model, there is no concern. Yes that is just "It's not a concern because you defined it to not be." but that is the reality for most users of Secure Boot on Linux. Also note that the reason I wrote that paragraph is because the HN submission was originally submitted with a title along the lines of "Every install of shim is affected".
- 3y ago