Skip to content

Comment on Reversing MikroTik's Silent Patch: The RouterOS 7.23.4 Fix They Wouldn't Explainparent

Comments

I’ve asked Claude to read this article for me and explain it to me. Somehow that makes it better, as then at least I know I’m talking to an AI:

“The fix closed two chained flaws in RouterOS’s shared crypto and login libraries: a lax PKCS#1 v1.5 RSA signature verifier that failed to enforce the total encoded length (256 bytes) or pin the digest to its correct length for the claimed hash, allowing an attacker to forge a valid-looking signature without the private key — a pre-auth authentication bypass sitting on SSH public-key auth, IPsec/IKE, and TLS simultaneously.

“The second flaw was missing input validation on the terminal-login username path (SSH, Telnet, MAC-Telnet), which permitted argument injection (a leading -) and control-character/log-forging injection.

“Chained, the forged-signature auth bypass plus the hostile login-parameter handling turned an unauthenticated network position into a path toward code execution, which is why MikroTik backported it silently across all branches on the same day.”

For anyone else reading this and rolling their own crypto (hint: don't! No really, just don't!):

a lax PKCS#1 v1.5 RSA signature verifier that failed to enforce the total encoded length (256 bytes) or pin the digest to its correct length for the claimed hash, allowing an attacker to forge a valid-looking signature without the private key

the correct way to do this is encode-then-memcmp(). You can't get it wrong that way because a memcmp() only has two outcomes, match or no match, not a whole range of "seems to work OK on the tests we ran it on".

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.