Few years ago I watched this engineer who used an rp3 to hack a bit locker encryption key.
That’s the scary part about security assumptions.
My word of advice; any security implementation by an actor who has a fiscal responsibility and/or incentive is inherently flawed.
You are handing your keys to a whore.
Microsoft gave up over a decade ago so this seems about right. If you want something secure get a Mac.
Crashstealer is still recent enough I see articles written about it.
If you want something secure learn secure practices.
Arch Wiki had pointed out for years that Secure Boot is a flawed mechanism.
It’s not flawed at all. But its purpose isn’t actually to secure anything. Its purpose is to complicate the installation of alternative OS and to perpetuate vendor lock in, while sounding like it’s “for your security”. In that regard, it has succeeded.
There is also TPM and Microsoft Pluton, which serve the same purpose.
A very large portion of Microsoft’s efforts are dedicated to this. If they redirected just a bit of their work force to fixing their products, maybe people would actually want to use them, instead of being forced to.
11 old and forgotten UEFI shim bootloaders at versions 0.9 and below that can be used to bypass UEFI Secure Boot on any UEFI-based machine that trusts Microsoft’s Microsoft Corporation UEFI CA 2011 third-party UEFI certificate authority (CA) certificate, regardless of the installed operating system (OS).
This “Trust” is one of my pet peeves. It’s $$$.
A PKI without a CRL will eventually become exploitable.
Secure boot does have a revocation mechanism (It’s literally how this issue has been mitigated) though.
You can not only load in allowed signatures, you can also load in disallowed ones so even properly signed binaries will get rejected.
I get why you’d dislike that wording, but this is also how all certificate stores work, regardless of whether we’re talking Secure Boot, Windows or Linux. Gotta trust the top level as providing legitimate certificates to then trust everything underlying as coming from the correct parties.
Certificate are something I work with constantly at work and I fucking hate resolving issues with them lol.
I get why you’d dislike that wording
It’s not just the wording.
this is also how all certificate stores work
Precisely.
Check out cacert.org and why it never gained “Trust”. Hint: $$$
Add this to the pile of reasons why M$ is a joke and people should stop using them. Nothing they make is so good that you need to stick around.
MS has mastered the one thing businesses love which is being perfectly mediocre. If you present a business two pieces of software one that does one thing really well but nothing else, and one that does three things terribly, they’ll pick the one that does three things terribly every time. That’s the MS design, it smears a thin coating of suck across as broad a surface as possible and then advertises that it does everything.
All it takes for it to be ‘broken’ is to be from Microslop.
IMO, broken ≠ vulnerable. Broken to me means it doesn’t work. There’s a difference, to me. 🤷♂️
If the “working” definition is “is secure”, and there’s 11 ways in which it’s not, is it not “insecure”, aka. “not working” then?
“Being secure” doesn’t seem to be the primary function of a “UEFI shim”, so no? 🤷♂️
Well considering that the “UEFI Shim’s” role is to sit in between a Microsoft owned certificate signing chain, it is certainly part of it’s primary role.
With Linux distributions supporting UEFI Secure Boot, the above-described Secure Boot mechanism built around Microsoft keys introduces some challenges. Every Linux distribution generates its own bootloader binaries, and each of them has a different hash. Getting every Linux bootloader signed directly by Microsoft would be slow, bureaucratic, and impractical (if not impossible) to maintain across all Linux distributions.
The solution to this problem is a shim: a small, minimal first-stage bootloader that Microsoft can vet and sign once, and which then creates a secondary trust anchor for the rest of the Linux distribution-specific boot stack – usually GRUB 2 and the Linux kernel. This trust anchor is another certificate, referred to as a vendor certificate (managed by the distribution vendor), added to the shim binary before it is signed by Microsoft.
Alright, good enough.
Forgotten UEFI shims undermining Secure Boot
Better?
I guess? I dunno. I’m not very good at boot systems.
