6 ms·

Exploiting signed bootloaders to circumvent UEFI Secure Boot (2019)

140 points by todsacerdoti 9mo ago

ronsor 9mo ago
(2019) The biggest weakness of secure boot was always third-party vendors shipping "insecure" bootloaders. It's a lot of work to verify signatures for every bit of data that gets loaded, especially on the PC platform.
- jeroenhd 9mo ago
  Thre original secure boot design would have had insecure bootloaders get blacklisted the moment abuse could be detected. Microsoft then made that system entirely useless by signing code that could be used to load unsigned code, like demonstrated here. They then also refused to blacklist their own broken bootloader to save sysadmins the time (who would need to deploy new recovery images and boot media containing the fixed bootloader). That vulnerable bootloader is particularly bad because it can be used to have the TPM unlock itself and give up the Bitlocker key, which the Linux loaders shouldn'tbe capable of even if they apply the bypass mentioned in the article. In a world where Microsoft cared about secure boot, they would blacklist the vulnerable Linux loaders as well as their own old bootloaders. Why Microsoft? Because they signed the files in the first place, only they can rescind the signatures. In that world, Linux users would call for Bill Gates' head for securing their security feature and sysadmins would be out for Steve Ballmer's blood for breaking their complex custom recovery system that nobody dares touch. Now we'll be stuck in the worst of both worlds.
  - gruez 9mo ago
    >They then also refused to blacklist their own broken bootloader to save sysadmins the time (who would need to deploy new recovery images and boot media containing the fixed bootloader). Source? The OP suggests they expect it to be blacklisted >I assume that Kaspersky bootloader signature certificate will not live long, and it will be added to global UEFI certificate revocation list, which will be installed on computers running Windows 10 via Windows Update If you search around you'll also find that microsoft does publish secure boot revocations, contrary to what you claim. https://github.com/fwupd/dbx-firmware https://github.com/fwupd/dbx-firmware
    - jeroenhd 9mo ago
      They blacklist some bootloaders, but it takes them forever. CVE-2023-24932 (from May 2023) had a fix available a year later (June 2024), had the update broadly made available through standard updates in 2025 (2 years later) and doesn't automatically install it today. You might think the 2025 update will solve the problem, but: > Before following these steps for applying the mitigations, install the Windows monthly servicing update released on July 8, 2025, or a later update on supported Windows devices. This update includes mitigations for CVE-2023-24932 but they are not enabled by default. All Windows devices should complete this step regardless of your plan to enable the mitigations. The current status for the update (https://support.microsoft.com/en-us/topic/how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d#bkmk_enforce https://support.microsoft.com/en-us/topic/how-to-manage-the-...) says: > The Enforcement Phase will not begin before January 2026, and we will give at least six months of advance warning in this article before this phase begins. When updates are released for the Enforcement Phase, they will include the following: Basically, unless your company and sysadmin have enforced this fix (i.e. you're a home user), Microsoft hasn't revoked their keys. Then there's CVE-2024-38058, a similar attack. Microsoft tried to roll out a fix, but that broke compatibility, and the fix was then rolled back. Again, that problem can be fixed with the solution for the previous CVE, but that is still not deployed by default. https://neodyme.io/en/blog/bitlocker_screwed_without_a_screwdriver/ https://neodyme.io/en/blog/bitlocker_screwed_without_a_screw... describes the TPM2 attack in detail as well as mitigations and solutions much better than I can.
  - rcxdude 9mo ago
    A better design would not involve a small default-trusted set of keys in the first place. If the signers were diverse and on equal footing, with users choosing who to trust, a single bad bootloader being signed would not compromise nearly the whole ecosystem.
  - Lucasoato 9mo ago
    I feel like this isn’t the best moment to call Bill Gates. Or maybe yes, maybe he’ll open source Windows at this point, who knows!
- mjg59 9mo ago
  Third party? Black Lotus was the first case we saw actually targeting individuals, and that was a vulnerability in the Windows bootloader.
Bratmon 9mo ago
It's really funny to me that Microsoft's attempt to finally stamp out desktop Linux once and for all failed because one of Microsoft's antivirus vendor partners couldn't write secure software to save their lives. The continued Linux desktop solely relies on antivirus vendors writing crappy insecure software. So we'll be fine forever.
- bri3d 9mo ago
  > It's really funny to me that Microsoft's attempt to finally stamp out desktop Linux once and for all failed This conspiracy was never true and never happened. First off, note that the first version of the thing in the article you’re commenting on relied on a Fedora shim loader which Microsoft signed. Second off, note that almost all modern motherboards let you enroll your own UEFI keys and do not rely on exclusively the Microsoft keys. The only place this is was becoming an issue for Linux was early Secure Boot implementations where the vendor was too lazy to allow key enrollment, and that era has generally passed.
  - yjftsjthsd-h 9mo ago
    I don't think it deserves quite that easy a dismissal; MS did lock down early UEFI+ARM devices and prohibit user-controlled keys (see the Windows RT devices as an example). Given their history of playing dirty, it's perfectly reasonable that people assumed this to be another play at undermining Linux, even if things didn't end up going that way.
    - bri3d 9mo ago
      By 2019, when the parent article was written, I don't think that was a good read on the situation. By 2026, when the parent comment was written, I really don't think it's a good read on the situation.
    - ls612 9mo ago
      I think that they definitely wanted to iOSify Windows but the colossal failure of Windows 8 and Windows RT led them to take a different approach.
bri3d 9mo ago
> Most motherboards include only Microsoft keys as trusted Is this really true, in 2019 when this was written or today? I haven’t seen a motherboard that didn’t let me enroll my own keys in a really long time. Laptops are a different story but even there, it’s been awhile. > Microsoft forbid to sign software licensed under GPLv3 because of tivoization restriction license rule Ah yes, GPLv3 is now Microsoft’s fault?
- NekkoDroid 9mo ago
  > Is this really true, in 2019 when this was written or today? This is true in the sense that they only ship with MS' keys as trusted, but all MoBos (including laptops) I had allow enrolling your own. Some might handle not having MS' keys better (or at all) than others, but it should in theory be possible to remove them, whether it will boot after is a different question (see option-ROM [1]) [1]: https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom
- TacticalCoder 9mo ago
  >Ah yes, GPLv3 is now Microsoft’s fault? You are missing the point. It's the fault of those who pushed SecureBoot down our throats (and don't get me wrong: I use SecureBoot) to have decided that Microsoft had both a free-pass to have its certs by default in every UEFI out there but no other certs. So users either have to understand how to enroll their own certs or to use a shim signed by... Microsoft. Let's not forget that we're talking about the company responsible for Windows 11 here.
  - bri3d 9mo ago
    > You are missing the point Of the GPLv3 sentence? No, it's dishonest rhetorically. Of the piece? Also I don't think so, exploiting the shims is a fun way to prove that Secure Boot is silly but we already knew that, and by 2019 claiming that "most" systems only allowed Microsoft keys is just flat out dishonest as well. > It's the fault of those who pushed SecureBoot down our throats (and don't get me wrong: I use SecureBoot) to have decided that Microsoft had both a free-pass to have its certs by default in every UEFI out there but no other certs. I really don't get this argument in general; Microsoft certs are enrolled by default as a combination of: a matter of convenience for majority users who are going to use Microsoft OSes, the unfortunate design of Option ROM signature checking, and the desire to get a Windows logo on the packaging and Microsoft OEM discounts. There's no Secure Boot or UEFI related reason that boards can't come in Setup Mode with no PK, and most industrial boards do indeed come this way, since they don't need Option ROMs and customers don't want a Microsoft logo. > So users either have to understand how to enroll their own certs or to use a shim signed by... Microsoft. This seems like the best outcome for end-user computers which will have Windows installed to me? Users get a computer that checks that the OS it came with is valid (well, tries to, but that's a different can of worms), and still have the option to do whatever they want with it if they so desire. They can choose the Microsoft signed shim for convenient dual-booting, or erase the platform keys and own their system end to end if they wish. > Let's not forget that we're talking about the company responsible for Windows 11 here. I've never really understood these arguments, and it's even weirder to bring Windows 11 into it. Is the thing we're railing against here Ballmer-Borg Microsoft? Shitty Product Management Kills Products Microsoft? AI Infested Microsoft? The Venn diagram of overlap between 1990s Microsoft (genesis of UEFI), 2012 Microsoft (Secure Boot introduction), and 2025 Microsoft (Windows 11) seems likely to be... quite small.
mjevans 9mo ago
Empowering the 'User' (hardware owner) should have always been the focus. From that mindset what makes sense are hardware vendors including a cache of trusted third party root certificates from known other vendors. Today this would include Microsoft, the same said hardware vendor, probably various respected Linux organizations/groups (Offhand, Linux Foundation, ArchLinux, Debian, IBM/RedHat, Oracle, SUSE, etc), similar for BSD... Crucially the end user should then be ASKED which to enable. None should be enrolled out of the box. They might also be enabled only for specific things. E.G. HW vendor could be enabled only for new system firmware signatures (load using the existing software) rather than generic UEFI boot targets. The user should also be able to enroll their own CA certs as well; multiple of them. Useful for Organization, Division Unit, and system local signatures. It would also, really, be nice if UEFI mandated a uniform access API (maybe it does) for local blobs stored in non mass-storage space. This would be a great place to stash things like UEFI drivers for accessing additional types of hardware drivers, OS boot bits + small related files, etc. I would have said 1GB of storage would be more than sufficient for this - however Microsoft has proven that assumption incorrect. Still it'd be nice to have a standard place and a feature that says the system ships with this much reliable secondary storage included (or maybe 1-2 micro-SD card slots, etc).
- mistrial9 9mo ago
  > Crucially the end user should then be ASKED which to enable except, on the other side of the "strange fellows" are people who rose to executive authority by ruthless focus on control of every aspect of their business, and profit including excluding others who did actual work. There is zero point zero chance of any argument that relies on "should" to work IMHO this is a political situation by definition -- vastly different yet connected members of society and economics, seeking the rule of law to enable stable markets. hint- some of the same decision makers are the ones that pay to put spy code in your large new TV or appliances.
- NekkoDroid 9mo ago
  > From that mindset what makes sense are hardware vendors including a cache of trusted third party root certificates from known other vendors. Today this would include Microslop, the same said hardware vendor, probably various respected Linux organizations/groups (Offhand, Linux Foundation, ArchLinux, Debian, IBM/RedHat, Oracle, SUSE, etc), similar for BSD... IMO systems should be shipped in "Setup Mode" by default with no keys preinstalled. On first boot which ever OS you decide to install should be able to enroll its keys. This way it is entirely agnostic of any cherrypicked list of "trust me" vendors. You'd still have most of the benefits of easy secure boot enrolling for those that don't know what it even is/how to do it while also allowing easy choosing of other OSes (at least on initial first boot). The main problem currently is option-ROM which has a tendency to cause the system to not even POST if secure boot is enabled without MS keys. Recently bricked a MoBo this way and even though it has 2 BIOS I can't actively choose which one to boot, it just has some "trust me, I know when" logic that chooses... well guess how well that is working for me...). The Asrock board I replaced it with though has an option for what it should do with such option-ROM when secure boot is active (don't run, always run, run if signed, ...) > The user should also be able to enroll their own CA certs as well; multiple of them. Useful for Organization, Division Unit, and system local signatures. Isn't this already the status quo?? > It would also, really, be nice if UEFI mandated a uniform access API (maybe it does) for local blobs stored in non mass-storage space. [...] I think UEFI is already complex enough and most of this can in a way already somewhat be handled by the EFI System Partition, e.g. systemd-boot can tell the UEFI to load (file system) drivers off of it (https://wiki.archlinux.org/title/Systemd-boot#Supported_file_systems https://wiki.archlinux.org/title/Systemd-boot#Supported_file...), I don't know if UEFI technically supports other types of drivers to be loaded.
charcircuit 9mo ago
The security story of the PC platform is such a mess due to fragmentation. I have way more trust in Apple's security here.
- varispeed 9mo ago
  Security through obscurity is not a great idea. This is what Apple's current approach is. For instance if your iPhone is infected with malware, there is no anti-virus software that can find it, because Apple doesn't let software to have such deep access that is needed for scanning.
  - charcircuit 9mo ago
    It's not security by obscurity. It's security by minimizing the attack service by being extremely picky about what you sign. When it is paramount that the code you sign is correct you can't go signing a ton of different projects from people who may not even care about security as much as you do. >For instance if your iPhone is infected with malware Then restarting it will remove it. So far Apple has had a perfect record with this unlike Android.
    - varispeed 9mo ago
      > Then restarting it will remove it. So far Apple has had a perfect record with this unlike Android. Not things like Pegasus. It does not minimise attack surface, but minimise ways _you_ can ensure there is nothing on the phone that shouldn't be there.
      - hollerith 9mo ago
        We're talking about the verification of the boot chain, and last I heard, Pegasus has never subverted that: its strategy is to break back in after every reboot.
        varispeed 9mo ago
vaxman 9mo ago
..was totally expecting this article to be written in Chinese, because it is an active attack vector being used to infiltrate western IT infrastructure by pre-loading spyware into the boot loaders, then clicked the article and the link opened to Cyrillic characters. Of course, APT29 is doing this too, but their agents aren't thought to be in the supply chain, so they have to infect the products after installation (using traditional hacking techniques). Look at how Intel ME and AMD PSP work and presume that something similar is in the latest Allwinner, Rockchip, Alibaba, and Nuclei, etc.. chips. To the Chinese, this seems fair because "the other Party" is doing it. Not arguing that it isn't, just that most customers have their head in the sand denying it is happening (even using them in IPKVMs!) There was also a Western paper on embedding hidden circuits (and thus functionality/ISAs) into CPUs and activating them in the field (after deployment) by executing a sequence of opcodes resulting in something akin to blowing a fuse on the processor die, thereby making the circuits invisible (to even a microscope) until activated. Those secret opcodes could then disable the chip or jump into a block of secret microcode and alter the program counter to behave in a non-standard manner so we might not easily be able to see what's happening, even if we knew to look. One still would have to deliver that secret sequence of opcodes to trigger such a stealth mode...that could be done via microcode/firmware updates from the manufacturer's website or an OS update, or similar techniques. Interestingly, an unexpected iteration of Chinese SoCs began flooding the markets just as the rest of the World was sustaining a "chip shortage" in a timeframe perfectly aligned with what would have been required to implement such a system after that paper was published. Air-gapping the customer's devices during installation (to prevent the activation opcode sequence) might not work either. Many Chinese SoCs are used as embedded peripherals simply to add WiFi, Bluetooth and Thread capabilities onto existing designs via a simple UART or doorbell interconnect. This makes it too easy for these Chinese SoCs to also be listening for a Morse-code-like activation signal on a low-frequency band, triggering the backdoor to open (enabling a more conventional remote code execution port or logic debugger exposed via WiFi or BLE for example, or causing malfunction or damage to what's on the GPIO or UART pins). Such low-frequencies could be disguised (think Blue Whale signals) so they might be sent slowly over great distances (or even from floating weather balloons or low earth orbit) without drawing too much suspicion. https://youtu.be/E-gbYjLd93g https://youtu.be/E-gbYjLd93g
jojomodding 9mo ago
And this, kids, is why you roll your own EFI keys.

140 points by todsacerdoti 9mo ago

(2019) The biggest weakness of secure boot was always third-party vendors shipping "insecure" bootloaders. It's a lot of work to verify signatures for every bit of data that gets loaded, especially on the PC platform.

jeroenhd 9mo ago
Thre original secure boot design would have had insecure bootloaders get blacklisted the moment abuse could be detected. Microsoft then made that system entirely useless by signing code that could be used to load unsigned code, like demonstrated here. They then also refused to blacklist their own broken bootloader to save sysadmins the time (who would need to deploy new recovery images and boot media containing the fixed bootloader). That vulnerable bootloader is particularly bad because it can be used to have the TPM unlock itself and give up the Bitlocker key, which the Linux loaders shouldn'tbe capable of even if they apply the bypass mentioned in the article. In a world where Microsoft cared about secure boot, they would blacklist the vulnerable Linux loaders as well as their own old bootloaders. Why Microsoft? Because they signed the files in the first place, only they can rescind the signatures. In that world, Linux users would call for Bill Gates' head for securing their security feature and sysadmins would be out for Steve Ballmer's blood for breaking their complex custom recovery system that nobody dares touch. Now we'll be stuck in the worst of both worlds.
- gruez 9mo ago
  >They then also refused to blacklist their own broken bootloader to save sysadmins the time (who would need to deploy new recovery images and boot media containing the fixed bootloader). Source? The OP suggests they expect it to be blacklisted >I assume that Kaspersky bootloader signature certificate will not live long, and it will be added to global UEFI certificate revocation list, which will be installed on computers running Windows 10 via Windows Update If you search around you'll also find that microsoft does publish secure boot revocations, contrary to what you claim. https://github.com/fwupd/dbx-firmware https://github.com/fwupd/dbx-firmware
  - jeroenhd 9mo ago
    They blacklist some bootloaders, but it takes them forever. CVE-2023-24932 (from May 2023) had a fix available a year later (June 2024), had the update broadly made available through standard updates in 2025 (2 years later) and doesn't automatically install it today. You might think the 2025 update will solve the problem, but: > Before following these steps for applying the mitigations, install the Windows monthly servicing update released on July 8, 2025, or a later update on supported Windows devices. This update includes mitigations for CVE-2023-24932 but they are not enabled by default. All Windows devices should complete this step regardless of your plan to enable the mitigations. The current status for the update (https://support.microsoft.com/en-us/topic/how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d#bkmk_enforce https://support.microsoft.com/en-us/topic/how-to-manage-the-...) says: > The Enforcement Phase will not begin before January 2026, and we will give at least six months of advance warning in this article before this phase begins. When updates are released for the Enforcement Phase, they will include the following: Basically, unless your company and sysadmin have enforced this fix (i.e. you're a home user), Microsoft hasn't revoked their keys. Then there's CVE-2024-38058, a similar attack. Microsoft tried to roll out a fix, but that broke compatibility, and the fix was then rolled back. Again, that problem can be fixed with the solution for the previous CVE, but that is still not deployed by default. https://neodyme.io/en/blog/bitlocker_screwed_without_a_screwdriver/ https://neodyme.io/en/blog/bitlocker_screwed_without_a_screw... describes the TPM2 attack in detail as well as mitigations and solutions much better than I can.
- rcxdude 9mo ago
  A better design would not involve a small default-trusted set of keys in the first place. If the signers were diverse and on equal footing, with users choosing who to trust, a single bad bootloader being signed would not compromise nearly the whole ecosystem.
- Lucasoato 9mo ago
  I feel like this isn’t the best moment to call Bill Gates. Or maybe yes, maybe he’ll open source Windows at this point, who knows!
mjg59 9mo ago
Third party? Black Lotus was the first case we saw actually targeting individuals, and that was a vulnerability in the Windows bootloader.

Bratmon 9mo ago

It's really funny to me that Microsoft's attempt to finally stamp out desktop Linux once and for all failed because one of Microsoft's antivirus vendor partners couldn't write secure software to save their lives. The continued Linux desktop solely relies on antivirus vendors writing crappy insecure software. So we'll be fine forever.

bri3d 9mo ago
> It's really funny to me that Microsoft's attempt to finally stamp out desktop Linux once and for all failed This conspiracy was never true and never happened. First off, note that the first version of the thing in the article you’re commenting on relied on a Fedora shim loader which Microsoft signed. Second off, note that almost all modern motherboards let you enroll your own UEFI keys and do not rely on exclusively the Microsoft keys. The only place this is was becoming an issue for Linux was early Secure Boot implementations where the vendor was too lazy to allow key enrollment, and that era has generally passed.
- yjftsjthsd-h 9mo ago
  I don't think it deserves quite that easy a dismissal; MS did lock down early UEFI+ARM devices and prohibit user-controlled keys (see the Windows RT devices as an example). Given their history of playing dirty, it's perfectly reasonable that people assumed this to be another play at undermining Linux, even if things didn't end up going that way.
  - bri3d 9mo ago
    By 2019, when the parent article was written, I don't think that was a good read on the situation. By 2026, when the parent comment was written, I really don't think it's a good read on the situation.
  - ls612 9mo ago
    I think that they definitely wanted to iOSify Windows but the colossal failure of Windows 8 and Windows RT led them to take a different approach.

bri3d 9mo ago

> Most motherboards include only Microsoft keys as trusted Is this really true, in 2019 when this was written or today? I haven’t seen a motherboard that didn’t let me enroll my own keys in a really long time. Laptops are a different story but even there, it’s been awhile. > Microsoft forbid to sign software licensed under GPLv3 because of tivoization restriction license rule Ah yes, GPLv3 is now Microsoft’s fault?

NekkoDroid 9mo ago
> Is this really true, in 2019 when this was written or today? This is true in the sense that they only ship with MS' keys as trusted, but all MoBos (including laptops) I had allow enrolling your own. Some might handle not having MS' keys better (or at all) than others, but it should in theory be possible to remove them, whether it will boot after is a different question (see option-ROM [1]) [1]: https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom
TacticalCoder 9mo ago
>Ah yes, GPLv3 is now Microsoft’s fault? You are missing the point. It's the fault of those who pushed SecureBoot down our throats (and don't get me wrong: I use SecureBoot) to have decided that Microsoft had both a free-pass to have its certs by default in every UEFI out there but no other certs. So users either have to understand how to enroll their own certs or to use a shim signed by... Microsoft. Let's not forget that we're talking about the company responsible for Windows 11 here.
- bri3d 9mo ago
  > You are missing the point Of the GPLv3 sentence? No, it's dishonest rhetorically. Of the piece? Also I don't think so, exploiting the shims is a fun way to prove that Secure Boot is silly but we already knew that, and by 2019 claiming that "most" systems only allowed Microsoft keys is just flat out dishonest as well. > It's the fault of those who pushed SecureBoot down our throats (and don't get me wrong: I use SecureBoot) to have decided that Microsoft had both a free-pass to have its certs by default in every UEFI out there but no other certs. I really don't get this argument in general; Microsoft certs are enrolled by default as a combination of: a matter of convenience for majority users who are going to use Microsoft OSes, the unfortunate design of Option ROM signature checking, and the desire to get a Windows logo on the packaging and Microsoft OEM discounts. There's no Secure Boot or UEFI related reason that boards can't come in Setup Mode with no PK, and most industrial boards do indeed come this way, since they don't need Option ROMs and customers don't want a Microsoft logo. > So users either have to understand how to enroll their own certs or to use a shim signed by... Microsoft. This seems like the best outcome for end-user computers which will have Windows installed to me? Users get a computer that checks that the OS it came with is valid (well, tries to, but that's a different can of worms), and still have the option to do whatever they want with it if they so desire. They can choose the Microsoft signed shim for convenient dual-booting, or erase the platform keys and own their system end to end if they wish. > Let's not forget that we're talking about the company responsible for Windows 11 here. I've never really understood these arguments, and it's even weirder to bring Windows 11 into it. Is the thing we're railing against here Ballmer-Borg Microsoft? Shitty Product Management Kills Products Microsoft? AI Infested Microsoft? The Venn diagram of overlap between 1990s Microsoft (genesis of UEFI), 2012 Microsoft (Secure Boot introduction), and 2025 Microsoft (Windows 11) seems likely to be... quite small.

mjevans 9mo ago

Empowering the 'User' (hardware owner) should have always been the focus. From that mindset what makes sense are hardware vendors including a cache of trusted third party root certificates from known other vendors. Today this would include Microsoft, the same said hardware vendor, probably various respected Linux organizations/groups (Offhand, Linux Foundation, ArchLinux, Debian, IBM/RedHat, Oracle, SUSE, etc), similar for BSD... Crucially the end user should then be ASKED which to enable. None should be enrolled out of the box. They might also be enabled only for specific things. E.G. HW vendor could be enabled only for new system firmware signatures (load using the existing software) rather than generic UEFI boot targets. The user should also be able to enroll their own CA certs as well; multiple of them. Useful for Organization, Division Unit, and system local signatures. It would also, really, be nice if UEFI mandated a uniform access API (maybe it does) for local blobs stored in non mass-storage space. This would be a great place to stash things like UEFI drivers for accessing additional types of hardware drivers, OS boot bits + small related files, etc. I would have said 1GB of storage would be more than sufficient for this - however Microsoft has proven that assumption incorrect. Still it'd be nice to have a standard place and a feature that says the system ships with this much reliable secondary storage included (or maybe 1-2 micro-SD card slots, etc).

mistrial9 9mo ago
> Crucially the end user should then be ASKED which to enable except, on the other side of the "strange fellows" are people who rose to executive authority by ruthless focus on control of every aspect of their business, and profit including excluding others who did actual work. There is zero point zero chance of any argument that relies on "should" to work IMHO this is a political situation by definition -- vastly different yet connected members of society and economics, seeking the rule of law to enable stable markets. hint- some of the same decision makers are the ones that pay to put spy code in your large new TV or appliances.
NekkoDroid 9mo ago
> From that mindset what makes sense are hardware vendors including a cache of trusted third party root certificates from known other vendors. Today this would include Microslop, the same said hardware vendor, probably various respected Linux organizations/groups (Offhand, Linux Foundation, ArchLinux, Debian, IBM/RedHat, Oracle, SUSE, etc), similar for BSD... IMO systems should be shipped in "Setup Mode" by default with no keys preinstalled. On first boot which ever OS you decide to install should be able to enroll its keys. This way it is entirely agnostic of any cherrypicked list of "trust me" vendors. You'd still have most of the benefits of easy secure boot enrolling for those that don't know what it even is/how to do it while also allowing easy choosing of other OSes (at least on initial first boot). The main problem currently is option-ROM which has a tendency to cause the system to not even POST if secure boot is enabled without MS keys. Recently bricked a MoBo this way and even though it has 2 BIOS I can't actively choose which one to boot, it just has some "trust me, I know when" logic that chooses... well guess how well that is working for me...). The Asrock board I replaced it with though has an option for what it should do with such option-ROM when secure boot is active (don't run, always run, run if signed, ...) > The user should also be able to enroll their own CA certs as well; multiple of them. Useful for Organization, Division Unit, and system local signatures. Isn't this already the status quo?? > It would also, really, be nice if UEFI mandated a uniform access API (maybe it does) for local blobs stored in non mass-storage space. [...] I think UEFI is already complex enough and most of this can in a way already somewhat be handled by the EFI System Partition, e.g. systemd-boot can tell the UEFI to load (file system) drivers off of it (https://wiki.archlinux.org/title/Systemd-boot#Supported_file_systems https://wiki.archlinux.org/title/Systemd-boot#Supported_file...), I don't know if UEFI technically supports other types of drivers to be loaded.

charcircuit 9mo ago

The security story of the PC platform is such a mess due to fragmentation. I have way more trust in Apple's security here.

varispeed 9mo ago
Security through obscurity is not a great idea. This is what Apple's current approach is. For instance if your iPhone is infected with malware, there is no anti-virus software that can find it, because Apple doesn't let software to have such deep access that is needed for scanning.
- charcircuit 9mo ago
  It's not security by obscurity. It's security by minimizing the attack service by being extremely picky about what you sign. When it is paramount that the code you sign is correct you can't go signing a ton of different projects from people who may not even care about security as much as you do. >For instance if your iPhone is infected with malware Then restarting it will remove it. So far Apple has had a perfect record with this unlike Android.
  - varispeed 9mo ago
    > Then restarting it will remove it. So far Apple has had a perfect record with this unlike Android. Not things like Pegasus. It does not minimise attack surface, but minimise ways _you_ can ensure there is nothing on the phone that shouldn't be there.
    - hollerith 9mo ago
      We're talking about the verification of the boot chain, and last I heard, Pegasus has never subverted that: its strategy is to break back in after every reboot.
      - varispeed 9mo ago

vaxman 9mo ago

..was totally expecting this article to be written in Chinese, because it is an active attack vector being used to infiltrate western IT infrastructure by pre-loading spyware into the boot loaders, then clicked the article and the link opened to Cyrillic characters. Of course, APT29 is doing this too, but their agents aren't thought to be in the supply chain, so they have to infect the products after installation (using traditional hacking techniques). Look at how Intel ME and AMD PSP work and presume that something similar is in the latest Allwinner, Rockchip, Alibaba, and Nuclei, etc.. chips. To the Chinese, this seems fair because "the other Party" is doing it. Not arguing that it isn't, just that most customers have their head in the sand denying it is happening (even using them in IPKVMs!) There was also a Western paper on embedding hidden circuits (and thus functionality/ISAs) into CPUs and activating them in the field (after deployment) by executing a sequence of opcodes resulting in something akin to blowing a fuse on the processor die, thereby making the circuits invisible (to even a microscope) until activated. Those secret opcodes could then disable the chip or jump into a block of secret microcode and alter the program counter to behave in a non-standard manner so we might not easily be able to see what's happening, even if we knew to look. One still would have to deliver that secret sequence of opcodes to trigger such a stealth mode...that could be done via microcode/firmware updates from the manufacturer's website or an OS update, or similar techniques. Interestingly, an unexpected iteration of Chinese SoCs began flooding the markets just as the rest of the World was sustaining a "chip shortage" in a timeframe perfectly aligned with what would have been required to implement such a system after that paper was published. Air-gapping the customer's devices during installation (to prevent the activation opcode sequence) might not work either. Many Chinese SoCs are used as embedded peripherals simply to add WiFi, Bluetooth and Thread capabilities onto existing designs via a simple UART or doorbell interconnect. This makes it too easy for these Chinese SoCs to also be listening for a Morse-code-like activation signal on a low-frequency band, triggering the backdoor to open (enabling a more conventional remote code execution port or logic debugger exposed via WiFi or BLE for example, or causing malfunction or damage to what's on the GPIO or UART pins). Such low-frequencies could be disguised (think Blue Whale signals) so they might be sent slowly over great distances (or even from floating weather balloons or low earth orbit) without drawing too much suspicion. https://youtu.be/E-gbYjLd93g https://youtu.be/E-gbYjLd93g

jojomodding 9mo ago

And this, kids, is why you roll your own EFI keys.