4 ms·
Reversing MikroTik's Silent Patch: The RouterOS 7.23.4 Fix They Wouldn't Explain
- semiquaver 1mo agoGod damn this writing is just a string of pure claudeisms. I can’t see the actual content because I’m cringing so hard. Why not just post the info you want to convey and the prompt? It would be easier for everyone involved.
- slaw3 1mo agoI agree. I would prefer just the info, if the write up was not human authored
- a2ff6eeb0 1mo agoThe info was also almost certainly not human authored. AI is almost certainly capable of writing this up given a prompt like "explain what this security update is about. Format it as a blog post."
- spdustin 1mo agoI'm so weary of seeing Claude-isms everywhere. It makes everything so much more of a cognitive burden to read, whether you're reading for leisure or comprehension.
- stingraycharles 1mo agoI’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 28d 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".
- pseudohadamard 28d agoai;dr
- a2ff6eeb0 1mo agoIt's incredible that we can have full security writeups done without a human involved at all.
- nicko170 1mo agoUsed to do this pre-AI - weeks, it would take many weeks to get this far. Now the things that can just be done in hours is absolutely incredible when using the tools as a force multiplier.
- a2ff6eeb0 1mo agoYeah! And now, people don't even need to understand the writeup, you can just ask the AI to read it and figure out the appropriate steps.
- realxrobau 1mo agoNick and I were at AusNOG when this dropped. Yes it was generated by AI, but it has evolved over time, and there has been at least three revisions of it. The three different issues are a username called "-2", incorrectly parsing/validating certificates, and tftp paths. There's also a dhcpd issue that was just fixed in a new release
- nicko170 1mo ago[flagged]
- yborg 1mo agoAll you had to do was to identify this as AI authored since it was going to be obvious anyway. Still valuable to have someone post the write-up.
- deleted 1mo ago[deleted]