Nikolaj Schlej

@CodeRush
647 Followers
49 Following
51 Posts
@alex @fay59 Learned the hard way on how to ensure the opposite outcome (aka "get all your bugs misrouted or closed before landing on your desk") - choose a component name that nobody but you and a few of your peers can ever know or intuit. Call your component "MySuperCoolObscureStarTrekReferenceCodeName | all" and enjoy bug-free life.

Published the third part of my blog series about Hydroph0bia (CVE-2025-4275) vulnerability, this one is about the fix as Insyde applied it, and my thoughts on improvements for it.

https://coderush.me/hydroph0bia-part3/

Hydroph0bia (CVE-2025-4275) - a fixed SecureBoot bypass for UEFI-compatible firmware based on Insyde H2O, part 3

@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.

Hydroph0bia (CVE-2025-4275) - a bit more than just a trivial SecureBoot bypass for UEFI-compatible firmware based on Insyde H2O, part 2

@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.