Re: CVE-2025-32433: Unauthenticated Remote Code Execution in Erlang/OTP SSH

[Solar Designer <solar () openwall com>]

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