5 ms·
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
by stingraycharles 12d ago
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.”
- pseudohadamard 10d agoFor 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".