←back to thread

198 points kimi | 1 comments | | HN request time: 0.245s | source
Show context
aftbit ◴[] 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 ◴[] 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. whizzter ◴[] No.43720311[source]
There's a huge difference here, historically that was because many C codebases were vulnerable due to inherent C flaws and ssh daemons due to their age was C based. OpenBSD folks stances on coding and system design avoids pitfalls.

This is an Erlang daemon, thus written in a managed language without buffer overflows,etc, but it seems like someone left a huge gaping logic hole to drive a bus through. SSH or not, this could've equally well been a logic hole in a base webserver,etc.

I'd say this is more akin to the Log4j debacle, a perfectly safe language but bad design makes it vulnerable to something trivial.