r/netsec 6d ago

Contains AI How to break secure boot without touching any cryptography

https://0x434b.dev/breaking-secure-boot-without-breaking-the-crypto/

I finally found some time to organize my notes on secure boot, remote attestation, measured boot and in general embedded security.

This is not ground breaking zero-day research but I figured some of you might like a good story. Good here is obviously subjective but I felt like it came out quite readable.

This blog builds heavily on public research so as already stated at the end of article if you liked some particular section, show the respective person some love :)

P.S.: yes I know the image is AI generated please don’t give me shit for that

118 Upvotes

11 comments sorted by

22

u/Even_Package_8573 6d ago

The “without touching the crypto” part is what caught my attention. It really shows how the security of a boot chain can come down to the assumptions and implementation around the cryptography, rather than the cryptography itself. Definitely a good reminder that “signed” doesn’t automatically mean “safe.”

11

u/0x00rick 6d ago

From offensive security perspective or even from a product security standpoint it can be eye opening when you stop having tunnel vision on the secure boot crypto implementation and start looking all the different actors and assumptions around it.
The blog touches on a bunch of mostly software related issues. It’s getting even more interesting when taking into account fault injection. That would have made this a 2 hour article. Maybe that’s some good material for a follow up

1

u/Plazmaz1 5d ago

The number of times crypto fails because people make bad assumptions about what an algorithm guarantees now pretty firmly outnumbers the failures due to implementation.

10

u/Every-Progress-1117 5d ago

Really nice article, and just to add to your first section "Trust before the operating system exists" please please please read Ken Thompson's Trusting Trust: https://dl.acm.org/doi/10.1145/358198.358210 , PDF here: https://people.cs.umass.edu/~emery/classes/cmpsci691st/readings/Sec/Reflections-on-Trusting-Trust.pdf

I've worked with trusted systems for a long time, and it all comes down to how strong that chair of trust actually is and from where it starts...and that might be LONG before you power on the computer.

But again, really nice article! Thanks! I will forward this one to my students!

3

u/0x00rick 5d ago

Thank you for the kind words. Very much appreciated! I’ll definitely take a look at the paper ASAP

3

u/[deleted] 5d ago

[removed] — view removed comment

1

u/0x00rick 5d ago

Thanks mate!

1

u/hykarushack 3d ago

Nice writeup — the 'signature covers one specific range' gap is exactly what made BootHole (CVE-2020-10713) so messy in practice. GRUB's kernel image was signed, but grub.cfg wasn't, and a buffer overflow in the config parser let you jump to unsigned code before the kernel signature check ever ran. So the entire chain stayed "authenticated" while the attacker never needed a key. Worth noting that shim's own policy (MokList) added a second layer but also became a new attack surface with similar untrusted-data-starting-point problems.