@mjg59 Remember the original Retina MacBook of 2015, that had a single USB-C 3.1 port for everything? I had to work on fixing the firmware for it, and my serial cable could not support both UART and charging, and EFI had no power management, so the thing drained its small battery in less than an hour. FUN TIMES!!! (Dear reader, if you represent an OEM making ultrabooks, please never do this!)

@enhancedscurry "This place is not a place of honor... no highly esteemed deed is commemorated here... nothing valued is here."

@vathpela Updated the image, added clarification, should be less confusing now.

@vathpela Anytime, it's clarifying for all of us, and for any future readers too.

@vathpela it is indeed the case, need to replace the image in part2 and explicitly state that. SecureFlashSetupMode is indeed set to zero, which limits trust to Insyde 1st-party software. The fact that a driver could run in such a mode is an oversight nevertheless, but I hope Insyde never signed any drivers with the same cert.

@vathpela No, this is specifically about things that are using SecureFlashCertData. I know for sure that it is possible to setup the FW to trust only Insyde 1st party code signed by the cert from DXE volume (set SecureFlashSetupMode to 0 instead of 1), but IDR if that is actually set like that now. Needs a bit more testing.

Second part of my Hydroph0bia (CVE-2025-4275) research: https://coderush.me/hydroph0bia-part2/

This one is about hijacking code execution during FW update, and overcoming a rather naive countermeasure that SecureFlashDxe driver tired to employ against us.

@enhancedscurry I'm alright, the worst part is over a month ago, now it's up for the body to recover, and so far it does really well, way better than I or doctors expected.

How to check if your FW is vulnerable to Hydroph0bia (CVE-2025-4275): obtain a BIOS dump or a BIOS update for your PC, open it in UEFITool NE, open Search window on Text tab (Ctrl+F), search for Unicode text "SecureFlashCertData".
If nothing had been found, our FW is fine. Otherwise it would be found in at least BdsDxe and SecurityStubDxe, this means your FW is very likely to be vulnerable.

@Rairii It's not just "the implementations are all weak", it's much more "the whole ordeal reeks of rushing and compromising, and both lead to a thing being garbage for everything it tries to achieve". Then we sprinkle some Linux shim (that sets it's keys as non-RT variable and it is the only protection for them) all over it, and the shitcake is compete, bon appetit!

@Rairii This is why ditching UEFI SecureBoot entirely after we just implemented a rather nice version of it for T2-based machines was one of the best decisions we at FWSEC made back in 2019. The shit is unsalvageable and needs to be redone from scratch, without NVRAM as trusted storage, without dumb SMM-based SetVariable, with a better interface than the vintage of 1998, with a better signature format than Authenticode (separate manifest files, anybody?), etc.

@Rairii All IBV are a about equally busted, if you ask me, and Insyde is not the worst among them, but here we have both a "never touch a thing that works" and "some rushed fix of 2012 might destroy all our SecureBoot without us noticing for over a decade", which is indeed both hilarious and disappointing.

The embargo is over, so here it is: https://coderush.me/hydroph0bia-part1/

I can't stress the "NEVER USE NVRAM AS TRUSTED STORAGE" part harder, but now we all have a very nice example of a thing to not ever do, or have your SecureBoot and FW updater signing being vulnerable to all people who can set non-volatile RT variables by calling a dedicated OS API.

@enhancedscurry Will ask Aurora or Yash to do so, I've left the mothership for a while (again, for real this time) to care for my health in a country where medicine makes sense and won't bankrupt you if you look at it funny.

@madcoder @enhancedscurry do invite me too, folks. Decision to not fix checkm8 and blackbird in a chip revision felt like a betrayal to everything we at FWSEC held dear, and to the previous decision to fuze Intel BootGuard off, because "our T2-based root of trust is much better". Yeah, all our fancy MacEFI security tech on x86 side being trivially bypassable by $3 Arduino, much better indeed...

@agraf Nope, one of the IBVs, so everybody using custom solutions are fine. Waiting for Vijay from CERT to reply to my DMs (it's currently both nighttime in the US and Saturday) to start the disclosure process.

@agraf Nope, worse.

Found a nice little SecureBoot bypass in a sizable bunch of UEFI firmwares, will share the details when able.
Meanwhile, this is the SHA2-256 of the PoC tool to trigger it:
530584749f90d187ac20f77c6d4bb2e09ec1c852090962dfab01c4274a8a6d2d

@mjg59 Placing keys into NVRAM was a costly mistake that will haunt UEFI for decades, and Linux shim placing its MOKList into non-authenticated NVRAM with just the absence of RT flag as a protection measure makes it all even worse.

@mjg59 This is why any self-respecting custom security solution for x86 will strive to replace UEFI SecureBoot with something that doesn't place all keys into a generic variable storage prone not only to a SPI programmer, but also to bugs in SMM, bugs in NVRAM drivers, bugs in WMI handlers, and so on.