Nikolaj SchlejJun 11, 2025

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

Show threadFarce MajeureJun 11, 2025
@CodeRush So what you're saying is that if someone is using, say, Kaspersky's FDE product, if you have Insyde firmware it's running during your firmware updates?
Show threadNikolaj Schlej
@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.
Jun 11, 2025 at 7:26pmWeb
Show threadFarce MajeureJun 11, 2025
@CodeRush Yeah, I got that part, but I was specifically thinking about this bit from your outro: "as it turns out the DriverXXXX load options are still being processed even in the firmware update mode." (I should have said as much.) Is it processing the drivers but not loading them unless they're 1st party signed?
Show threadNikolaj SchlejJun 11, 2025
@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.
Show threadFarce MajeureJun 11, 2025
@CodeRush thanks for clarifying for me.
Show threadNikolaj SchlejJun 11, 2025
@vathpela Anytime, it's clarifying for all of us, and for any future readers too.
Show threadNikolaj SchlejJun 11, 2025
@vathpela Updated the image, added clarification, should be less confusing now.