5 ms·
This is kind of weird in that it's exploiting a vulnerability in the Windows bootloader, but once exploited it's pivoting to using shim+grub (edit: apparently i
by mjg59 4y ago
This is kind of weird in that it's exploiting a vulnerability in the Windows bootloader, but once exploited it's pivoting to using shim+grub (edit: apparently it's not actually grub, it's their own bootloader that's just called grubx64.efi because that's what shim boots by default). There's no absolute requirement to do this, but it's presumably easier to implement their full payload in grub rather than getting it all running in the context of the Windows bootloader. This means it probably doesn't work on the Secured Core PCs that only ship with support for the Windows signing key (but also it can't be used to attack Linux systems that remove trust in the Windows key).
This pivot means that the keys measured into PCR 7 of the TPM will change, which breaks the Bitlocker policy, which is presumably why stage 1 disables Bitlocker before exploiting the bootloader. This means it's also detectable using Remote Attestation (I think Microsoft's Device Health Attestation ought to notice, but haven't verified it), which is nice for all 3 of the people who've rolled that out.
In terms of why the known vulnerable bootloaders weren't already revoked - I have no inside knowledge here, but my guess would be the impact on users with existing install media (including factory restore images). We've revoked a bunch of vulnerable Linux bootloaders, but the level of pain involved in revoking a Windows one is almost certainly way higher.
- AshamedCaptain 4y ago> We've revoked a bunch of vulnerable Linux bootloaders, but the level of pain involved in revoking a Windows one is almost certainly way higher. Revoking other OSes install media en-masse is fine, but not Windows ?
- Sunspark 4y agoLinux users tend to be their own support. Windows users are commercial support which is $.
- LoganDark 4y agoYou can't exactly swap out the bootloader on Windows install media. You can on Linux because it's a modular component of the system, but on Windows the entire OS + kernel + bootloader is a single image.
- deleted 4y ago[deleted]
- michaelt 4y agoI wouldn't be surprised if 50% of Linux users already have Secure Boot disabled - and probably 98% of Linux users have the wherewithal to get into the BIOS and disable it if they needed to. And doing so has negligible downsides, as almost nobody on Linux has been fool enough to make use of the TPM.
- candiddevmike 4y agoTPM support on Linux (for drive encryption) is getting better with tools like clevis. Additionally, systemd can do a ton of cool things with TPM, and projects like dm-verity can make linux's boot process more locked down than Windows. I personally will always use a passphrase for device encryption.
- Laaas 4y agoPassphrase + TPM is best.
- cryptonector 4y ago> [...] almost nobody on Linux has been fool enough to make use of the TPM. Can you elaborate as to what is foolish about using a TPM?
- ghostpepper 4y agoNot the OP but just anecdotally, last time I looked into enabling secure boot on my X1 Carbon there was an advisory from Lenovo that enrolling your own keys made it possible to brick the machine https://wiki.archlinux.org/title/Lenovo_ThinkPad_X1_Carbon_(Gen_7) https://wiki.archlinux.org/title/Lenovo_ThinkPad_X1_Carbon_(...
- privacyking 4y agoThat's only if you fail to enroll the Lenovo hardware firmware images
- mjg59 4y agoOh, I think the vulnerable Windows images should also be revoked, but pretending that the damage caused is equivalent isn't realistic. Systems have shipped with factory restore partitions that still contain old bootloaders - this revocation update would stop all of those working, which is going to be a significant support burden for all those manufacturers.
- makomk 4y agoThe write-up I saw suggests that revoking the Windows bootloader would cause existing install and restore images to fail to boot even with Secure Boot disabled because it checks its own signature, which would be pretty amazing if true: https://github.com/Wack0/CVE-2022-21894 https://github.com/Wack0/CVE-2022-21894
- amluto 4y agoI continue to dislike the PCR 7 mechanism. Remote attestation, etc should have a means to accept or reject specific bootloaders, not just their signing keys. </grump>
- mjg59 4y agoThat information is still in PCR 4, the reason for just encoding the policy and signing key in PCR 7 is that it remains stable even if you update the bootloader.
- amluto 4y agoHmm, I guess there could have been a mechanism by which a boot manager would, as the very first thing it does, extend a PCR with its own version number, and other later things that want to require a specific or newer version could check that PCR. Then at least old versions could be reliably distrusted without actually being revoked and thus rendered unable to boot.
- mjg59 4y agoMeasuring the version is easy enough, and having that in the event log makes it easy to parse out remotely, but given the PCR is just going to end up as the SHA256 of it you can't write policy that says "Unlock if this value is x or greater". There's some stuff you could do with a monotonic counter, but they have some subtly complicated semantics that would make me a little scared of trying.
- amluto 4y agoI realize it would need SGX or make TPM even more horribly complicated, and the TCG has about zero change of getting it right, but it would be really nifty if one could unseal data based on a flexible predicate that can read the event log. Imagine something like an eBPF or Ethereum VM program that takes the event log as input and says yea or nay.
- trelane 4y ago
- pl4nty 4y agoRemote Attestation (DHA) is enabled by default with Microsoft's mobile device management product (Intune), so it's likely rolled out to a good number of enterprise customers. Not sure how many use DHA for access control though, and Intune doesn't support servers.