[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5134cbea-7c3f-4270-b70d-70d624fb6044@rub.de>
Date: Fri, 18 Apr 2025 14:01:44 +0200
From: Fabian Bäumer <fabian.baeumer@....de>
To: oss-security@...ts.openwall.com
Subject: Re: CVE-2025-32433: Unauthenticated Remote Code
Execution in Erlang/OTP SSH
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.
### Details
Let 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.
>
> ### Impact
>
> The 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.
>
> ### Mitigation
>
> Users 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.
>
> ### Advisory
>
> An official advisory is available on GitHub:
> https://github.com/erlang/otp/security/advisories/GHSA-37cp-fgq5-7wc2
>
> Best regards,
>
> Fabian Bäumer
>
Download attachment "smime.p7s" of type "application/pkcs7-signature" (6214 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
