←back to thread

Unauthenticated Remote Code Execution in Erlang/OTP SSH

(nvd.nist.gov)
198 points kimi | 4 comments | 17 Apr 25 13:29 UTC | HN request time: 0.001s | source
Show context
aftbit ◴[17 Apr 25 14:28 UTC] No.43717385[source]▶
As I understand it, this is talking about an SSH server built into Erlang/OTP, not e.g. OpenSSH on a server with Erlang installed.

>Any service using Erlang/OTP's SSH library for remote access such as those used in OT/IoT devices, edge computing devices are susceptible to exploitation.

https://thehackernews.com/2025/04/critical-erlangotp-ssh-vul...

replies(2): >>43717937 #>>43719581 #
rollcat ◴[17 Apr 25 17:06 UTC] No.43719581[source]▶
This is why I generally do not rely on SSH servers other than OpenSSH. It's (by far) the most widely deployed implementation, thoroughly battle-tested, etc. It's also hard to actually get pwned; the OpenBSD[1] guys believe in security as the default.

There's some value in avoiding a monoculture, or choosing different trade-offs (e.g. binary size, memory usage). But as exemplified by this incident, any incentives must be carefully weighted against the risks. SSH is your final line of defence.

[1]: https://www.openbsd.org/donations.html

replies(3): >>43720311 #>>43720798 #>>43722007 #
1. VWWHFSfQ ◴[17 Apr 25 20:41 UTC] No.43722007[source]▶
OpenSSH has actually been "pwned" numerous times though. It's a very desirable target.
replies(2): >>43724022 #>>43725818 #
2. throwawaymaths ◴[18 Apr 25 01:25 UTC] No.43724022[source]▶
yeah and iirc erlang's ssl was one of the only ssl implementations not affected by heaetbleed since erlang is memory safe
replies(1): >>43734767 #
3. rollcat ◴[18 Apr 25 07:24 UTC] No.43725818[source]▶
I think in case of any security-critical project it's important to evaluate the track record objectively:

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=OpenSSH

It's true that there are 5 advisories so far in this year alone, but let's consider the actual impact:

    CVE-2025-32728 - Error in documentation, possibly leading to misconfiguration
    CVE-2025-30095 - Debian+dropbear-specific
    CVE-2025-27731 - Windows-specific; local privilege escalation; OpenSSH doesn't target/support Windows
    CVE-2025-26466 - Remote DoS
    CVE-2025-26465 - MitM involving host key DNS verification; high attack complexity (relies on exhausting client memory)
OpenBSD enables sshd(8) in the default install, and has so far had two RCEs in 30 years. Now, not everyone runs OpenBSD, but I'd personally throw the stones at e.g. Debian (see CVE-2008-0166).
4. toast0 ◴[19 Apr 25 07:07 UTC] No.43734767[source]▶
I'm a big fan of Erlang, but I don't think this is a fair thing to praise.

Only OpenSSL had heartbleed. No other implementation of TLS protocols was affected. Many systems integrate with OpenSSL's protocol code, but there's also several that do their own protocol work and use ciphers from OpenSSL (and some that do both).

Erlang's ssl implementation at the time of heartbleed wasn't anywhere close in throughput to using OpenSSL separately. If I'm remembering right, OTP 18 (June 2015) is when it got good enough that it made more sense to run an Erlang https server without a separate TLS termination daemon. Heartbleed became known April 2014, so Erlang SSL was too late to help there, really. More secure, but unusable wirh load doesn't help much.

Also, Erlang SSL was one of many implementations thst needed to be reminded of 1998 era security issues in 2017. [1]

[1] https://nvd.nist.gov/vuln/detail/CVE-2017-1000385