Unauthenticated Remote Code Execution in Erlang/OTP SSH

If I interpret the patch correctly the issue seems to be that you could just ask for a channel and do a request_exec before authenticating. The regression test is:

    {send, hello},
    {send, ssh_msg_kexinit},
    {match, #ssh_msg_kexinit{_='_'}, receive_msg},
    {send, SshMsgChannelOpen},
    {send, SshMsgChannelRequest},
    {match, disconnect(), receive_msg}

https://github.com/erlang/otp/commit/6eef04130afc8b0ccb63c9a...

edit: Ah, found by the people at RUB, they do a lot of research in verifying protocol implementations iirc.

CWE-306, Missing Authentication for Critical Function, linked in the report seems to suggest the same. The score of 10.0 is damn spicy, too - you just ask the server to execute something for you, and it does so, no questions asked.

Design bug here: Clearly we need to run code as somebody, so, there's no reason to have infrastructure which just executes user code with the current context or server (presumably? or maybe an actual zero, ie root) context.

If we design the software this way, when we try to write the erroneous code we're caught - oh, wait, which user is authenticated? We need to... oh... we shouldn't be here without authenticating.

I'm vaguely surprised that https://www.runzero.com/sshamble/ didn't find this. They did a scan over the entire internet trying invalid SSH state machine transitions, which I guess didn't cover this sequence.

Afaik, if you were running the Erlang SSH daemon, when you connect as an authorized user (or just ask!), it drops you into the Erlang debug shell. There's no concept of different users in the debug shell. Erlang dist is kind of an almost single system image cluster, with no security boundaries once you're connected to the cluster. (Well, not exactly no boundaries, you can mark a process sensitive, and ets tables private, and do some other things to make introspection difficult [1], but you can likely still spawn an os process debugger and get to everything; you would need to modify the OTP sources to disable os process spawning)

I didn't think anybody would actually run the Erlang SSH daemon, but there's evidence that some do. It makes more sense to run openssh, so you can debug BEAM failures etc, and you can load a debug shell from your OS shell easily.

[1] https://security.erlef.org/secure_coding_and_deployment_hard...

>RUB

For those not in-the-know, this is "Ruhr University Bochum".

https://www.ruhr-uni-bochum.de/en

They have quite a good reputation in the security research space.

> The issue is caused by a flaw in the SSH protocol message handling which allows an attacker to send connection protocol messages prior to authentication.

per https://www.openwall.com/lists/oss-security/2025/04/16/2

I was too! The reason is that the Go x/crypto/ssh library was bailing out on the lack of reply to the channel open request, which prevented it from reaching the auth bypass check via exec. I should have an update out soon with this fixed and a RCE check for this issue.

The test server: $ erl -eval 'ssh:start(), ssh_dbg:on(), ssh:daemon(34222, [{system_dir, "/home/otp/ssh/keys"},{user_dir, "/home/otp/ssh/users/otptest/.ssh"}]).'

The exploit: auth.ScrapeExec(options, addr+" "+tname, res, ses, `os:cmd("touch /tmp/HAXXXED").`)

>-rw-r--r-- 1 root root 0 Apr 17 16:14 /tmp/HAXXXED