Nikolaj Schlej

@CodeRush
647 Followers
49 Following
51 Posts

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

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

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.

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.

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

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

A lot of people think I'm being sarcastic here, which is fair because I only went toe-to-toe against people on Twitter and didn't do much here, so I'll state my full opinion below anyhow:

I would agree with anyone about not wanting to replace C (or C++). But, C has been alive for 50 years (or just 35 from C89) and Rust has been alive for just barely under 10 (since Rust 1.0). Even if you measure the last 10 years of Rust versus the last 10 years of C or C++, one of these languages is making leaps and bounds ahead in providing people better primitives to do good work.

SafeInt secured pretty much all of Microsoft Office from some of the hardest bugs back in, around, 2005. C++ still lacks safe integer primitives; C only just got 3 functions to do overflow-checked math in C23, after David Svoboda campaigned for years. Rust just... has them baked into the standard library, for all the types you care about, too.

Similarly, people have been having memory issues in C and C++ for a while too. Most of the way to get better has been clamping down on static analysis and doing more testing, but we're still getting these errors. Meanwhile, teams writing Rust have been making way less errors on this in all the openly-published data from corporations like Google, and privately we are hearing a lot more about people taking complex financial and parsing code and turning it into Rust and having a fraction of the issues.

Even if I want to see C doing better, I have to acknowledge we were (a) too slow and not brave enough to do the things that could fix these portions of the language; (b) have fundamental design issues in the language itself that make ownership impossible to integrate as part of the language without breaking a ton of code; (c) do not provide good in-language tools and keep depending on vendors to "do the right thing" (i.e. adding or expanding U.B. and then just saying "vendors will check it" rather than taking responsibility with our language design); (d) are moving monumentally too slow to address the needs of the industry that many people -- especially security people -- have been yelling about since the mid 90s.

As much as I just want to pretend that I can write off every developer with "haha lole skill issue test better sanitize better IDIOT", if the root cause on this bug is "there was some C and/or C++ code that looked nominally correct but did batshit insanity in production", we absolutely will have problems to answer for. This doesn't absolve CrowdStrike for cutting 100s of workers and playing fast and loose, this doesn't excuse the fact that hospitals went down and people likely dead from lack of access to care, this doesn't change that it's abhorrent to have unmitigated hardware access in Ring0 just for a "security product", which has been the trend of every app wanting to plug in its own RootKit-like tool just for the sake of "app security" lately (League, NProtect, School Exam Spyware, etc.). There's a LOT of levels of "what the fuck have we let happen?" in play here, but I don't control those other levels.

I'm responsible for C, so I'm gonna look at the C bit. Other people responsible for the other parts of this stack should, hopefully, take sincere responsibility for those parts. (I doubt it, though, lmao.)

Still doing UEFITool release announcements on the bird site here: https://twitter.com/uefitool
Today it's the move to Qt6 day for the tools there, and we got UI dark mode support from it. If you use UEFITool NE, take this new build for a spin, as the switch for new lib and 64- bit builds on Windows might uncover some previously hidden bugs. Thanks in advance!
uefitool (@uefitool) / Twitter

Twitter
I'm still more active on Twitter than here, but it feels more "userinyerface" every day, with endless stream of suggested tweets for topics I explicitly asked to never show a dozen of times already, and now with this added "you might like" thing that I absolutely and certainly will not like. It's inevitable conclusion of their attempts to recover at least some money, but some crimes against UX can't remain unpunished forever.

Looks like an introduction post is ~5 years overdue, but whatever.

Hi folks, I'm Nikolaj Schlej aka CodeRush, you might know me as UEFI forward and reverse engineer, UEFITool author, or Apple FWSEC team member.

I usually post threads on various UEFI quirks I'm stumbling upon during UEFITool development and testing, unsolicited advices to other firmware engineers, frustrations from firmware security being broken and other similar FW fluff.

Will likely Xpost here from Twitter from now on.