Hi all,I would like to follow up on my last post with a few more details, now that people had a chance to act and public PoCs for CVE-2025-32433 are available.
### DetailsLet me start with a brief introduction to the SSH protocol. The SSH protocol is not one protocol but three: the transport layer protocol (RFC4253), the authentication protocol (RFC4252), and the connection protocol (RFC4254). The transport layer protocol handles most of the cryptography of SSH by negotiating algorithms, performing the key exchange, and establishing a secure channel to use with the other two protocols. The authentication protocol is responsible for client authentication (server authentication is done earlier in the transport layer). And lastly, the connection protocol provides all the application layer features people know of SSH, such as remote shells, port forwarding, and so on. To implement these features, the connection protocol uses a mechanism to divide the secure channel into multiple logical channels. Usually, the protocols are executed in order. First, the transport layer protocol establishes a secure channel, then the client authenticates itself, and eventually, the client can start opening channels and spawning shells.
Now, what went wrong here is that the server did not properly check the current protocol stage when receiving messages from the connection protocol. That is, the server allowed the client to send connection protocol messages during the transport layer's handshake. Therefore, a client can simply ask for a channel by sending an SSH_MSG_CHANNEL_OPEN message and follow up with an SSH_MSG_CHANNEL_REQUEST message of type exec. This type of channel request asks the server to execute the command (as Erlang code) contained within it without spawning a shell.
A minimalistic message flow that can exploit this vulnerability looks like this, that is also used by all PoCs that I have seen so far:
Client Server -------Version Banner-------> <-------Version Banner------- ------SSH_MSG_KEXINIT-------> <------SSH_MSG_KEXINIT-------- ----SSH_MSG_CHANNEL_OPEN----> --SSH_MSG_CHANNEL_REQUEST--->Now, what prevented detection of this vulnerability by tools like SSHambles, is that the server does not respond to these requests. However, as it turns out, this is not true. The server does respond to the request, sending the actual command output to the client, but only after the SSH handshake is concluded (i.e., the SSH_MSG_NEWKEYS has been sent). For our PoC, we used os:cmd("cat /etc/passwd"). as the payload of the channel request and obtained the contents of /etc/passwd over the same connection. The message flow looks something like this (the additional channel request sent by the server is of type exit-status):
Client Server --------Version Banner-------> <-------Version Banner-------- -------SSH_MSG_KEXINIT-------> <------SSH_MSG_KEXINIT-------- -----SSH_MSG_CHANNEL_OPEN----> ---SSH_MSG_CHANNEL_REQUEST---> ----SSH_MSG_KEX_ECDH_INIT----> <----SSH_MSG_KEX_ECDH_REPLY--- <-------SSH_MSG_NEWKEYS------- --------SSH_MSG_NEWKEYS------> <---SSH_MSG_CHANNEL_SUCCESS--- <-----SSH_MSG_CHANNEL_DATA---- <-----SSH_MSG_CHANNEL_EOF----- <---SSH_MSG_CHANNEL_REQUEST--- <----SSH_MSG_CHANNEL_CLOSE----The fix for this vulnerability is rather simple. The server must simply check whether the client is authenticated when receiving connection protocol messages and disconnect if this is not the case. And this is exactly what the patch by the Erlang/OTP team does.
Best regards, Fabian Bäumer M. Sc. Fabian Bäumer Chair for Network and Data Security Ruhr University Bochum Universitätsstr. 150, Building MC 4/145 44780 Bochum Germany Am 16.04.2025 um 19:28 schrieb Fabian Bäumer:
Hi all,we (Fabian Bäumer, Marcus Brinkmann, Marcel Maehren, Jörg Schwenk (Ruhr University Bochum)) found a critical security vulnerability in the Erlang/OTP SSH implementation. The vulnerability allows an attacker with network access to an Erlang/OTP SSH server to execute arbitrary code without prior authentication. This vulnerability has been assigned CVE-2025-32433 with an estimated CVSSv3 of 10.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H). 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.### Am I affected?All users running an SSH server based on the Erlang/OTP SSH library are likely to be affected by this vulnerability. If your application uses Erlang/OTP SSH to provide remote access, assume you are affected.### ImpactThe vulnerability allows an attacker to execute arbitrary code in the context of the SSH daemon. If your SSH daemon is running as root, the attacker has full access to your device. Consequently, this vulnerability may lead to full compromise of hosts, allowing for unauthorized access to and manipulation of sensitive data by third parties, or denial-of-service attacks.### MitigationUsers are advised to update to the latest available Erlang/OTP release. Fixed versions are OTP-27.3.3, OTP-26.2.5.11, and OTP-25.3.2.20. As a temporary workaround, access to vulnerable SSH servers can be prevented by suitable firewall rules.### AdvisoryAn official advisory is available on GitHub: https://github.com/erlang/otp/security/advisories/GHSA-37cp-fgq5-7wc2Best regards, Fabian Bäumer
smime.p7s
Description: Kryptografische S/MIME-Signatur
