Every so often you open a binary expecting a quiet afternoon and instead find a parser that trusts the network more than it trusts itself. This is one of those afternoons. What follows is the full chain — from an unassuming length field to a clean pre-authentication remote code execution — in a product that, per its own marketing, is used by “the world’s most demanding organizations.”
The bug
The service exposes a length-prefixed protocol over TCP. A single field controls how many bytes are copied into a fixed-size stack buffer. It is validated exactly as much as you’d fear:
uint16_t len = ntohs(hdr->length);
char buf[256];
memcpy(buf, payload, len); // len is attacker-controlled, up to 65535There is no upper-bound check. There is a comment two lines up that says // TODO: validate. It has been there, according to git blame, since 2019.
Reaching the vulnerable path
The interesting part is that this runs before authentication. The handshake parser is invoked the moment a connection is accepted, which means the only prerequisite for triggering the overflow is the ability to open a socket — a bar the entire internet clears comfortably.
From crash to control
Stack canaries are present, which is polite of them, but the overflow reaches the saved return address before the cookie check matters in one specific error path. From there it is a standard ROP chain into a mprotect() gadget and a short stager. Nothing exotic — the vulnerability did all the exotic work already.
With ASLR in the way, a blind attempt has to guess the base. On a 64-bit target with the usual 28 bits of mmap entropy, the odds of a single blind guess landing are
which is exactly why the info-leak in the previous handshake field is doing so much quiet, load-bearing work here.
Disclosure
I reported it. Ninety days later the advisory shipped, describing the fix as a “stability improvement.” I am choosing to read that as a compliment.