Hi Alexander,
We used a technique called state machine learning to infer the state machine of the Erlang/OTP SSH server by interaction. With the state machine at hand, we noticed unexpected state transitions during the handshake caused by SSH_MSG_CHANNEL_OPEN messages. In particular, sending SSH_MSG_CHANNEL_REQUEST without SSH_MSG_CHANNEL_OPEN caused the connection to terminate, while sending SSH_MSG_CHANNEL_OPEN first changed this behavior. This led us to suspect Erlang/OTP SSH might be vulnerable to early connection protocol message injection—which turned out to be true.How did your team find this vulnerability? Manual auditing? Different tool? A formal verification project?
For others looking this up, it's actually SSHamble (without the "s"):
Thanks for the correction :) 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 19.04.2025 um 01:20 schrieb Solar Designer:
Hi Fabian, Thank you very much for this discovery and for the additional detail. On Fri, Apr 18, 2025 at 02:01:44PM +0200, Fabian Bäumer wrote:Now, what prevented detection of this vulnerability by tools like SSHambles, is that the server does not respond to these requests.For others looking this up, it's actually SSHamble (without the "s"): https://www.runzero.com/sshamble/ https://github.com/runZeroInc/sshamble How did your team find this vulnerability? Manual auditing? Different tool? A formal verification project?### 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.This has some additional detail on Elixir/Phoenix: https://paraxial.io/blog/erlang-ssh "The default configuration for Phoenix does not expose the Erlang SSH daemon to the public internet. It is technically possible you are vulnerable if your application does expose Erlang's SSH daemon, for example Elixir sftp clients do this." Regarding Matt Keeley's exploit I posted yesterday, they now have a blog post explaining how the exploit was created mostly by AI: https://platformsecurity.com/blog/CVE-2025-32433-poc That's very impressive, although it might have been helped by the fix containing a regression test, which already was almost a public PoC: https://github.com/erlang/otp/commit/6eef04130afc8b0ccb63c9a0d8650209cf54892f#diff-156a6329570e311c82b40c32d19acb37ef6d03339219ea18cd2a2a4e5649c8e5R390 as it included the main steps: early_rce(Config) -> [...] {send, hello}, {send, ssh_msg_kexinit}, {match, #ssh_msg_kexinit{_='_'}, receive_msg}, {send, SshMsgChannelOpen}, {send, SshMsgChannelRequest}, Alexander
smime.p7s
Description: Kryptografische S/MIME-Signatur
