This video shows my PoC for libssh CVE-2023-2283 (authentication bypass vuln). The attacker logs in with ED25519 authentication, despite not knowing the private key.

The PoC is slow, unreliable, and very noisy. Don’t say I didn’t warn you!

To trigger the bug, the attacker needs to trigger an out-of-memory error on a very small allocation (72 bytes).

The PoC generates a massive amount of memory pressure by sending a large number of bogus “service request” messages with zlib compression. The PoC doesn’t read the replies, which causes the server’s send buffer to fill up rapidly.

So generating memory pressure isn’t difficult, but causing the server to run out of memory at exactly the right moment that it’ll cause a 72-byte allocation to fail is.

I tried a variety of strategies and wasted quite a bit of time examining the structure of the malloc arenas, etc. Couldn’t get anything to work.

But then I remember the strategy that worked for CVE-2021-3939, which I call “embrace the chaos”.

My PoC was triggering plenty of out-of-memory errors, but not the right ones. So I thought: what if I run 3 copies of the PoC on a loop at the same time? 🤣

And that works. 🤦 Three attackers continuously bombarding the server causes enough out-of-memory errors that eventually one of the attackers gets lucky. 🥳

I even added a signaling mechanism so that the successful PoC can notify the other two to stop running: it writes a file named “success.txt”. Pure quality!👌

A few caveats about this PoC: Caveat 1: libssh is not openssh. (But it’s widely used.) Caveat 2: libssh is a library, which means that the exploitability of this bug depends on how the library is used. My PoC targets the demo ssh server from the “examples” subdirectory.

Caveat 3: The bug is only exploitable in a memory-constrained environment such as a memory-constrained container. I am running libssh with a 256MB memory limit to simulate this.

Source code for the PoC: