Why are we all still running an ssh server written in an unsafe language in 2024?
What is the better working alternative?
RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
171–180 of 347 posts
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#172Quoting some ska tune in a SSH vulnerability report really caught me off ward, but I loved it.
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#173> Exploitation on non-glibc systems is conceivable but has not been examined. ( https://www.openssh.com/txt/release-9.8 ) Darn - here I was hoping Alpine was properly immune, but it sounds more like "nobody's checked if it works on musl" at this point.
> OpenSSH sshd on musl-based systems is not vulnerable to RCE via CVE-2024-6387 (regreSSHion).
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#174After the xz backdoor a few months ago, I decided to turn off SSH everywhere I don't need it, either by disabling it or uninstalling it entirely. While SSH is quite secure, it's too lucrative a target, so it will always pose a risk.
So .. how do you handle remote logins?
"everywhere I don't need it" likely implies computers he or she only accesses directly on the console.
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#175After the xz backdoor a few months ago, I decided to turn off SSH everywhere I don't need it, either by disabling it or uninstalling it entirely. While SSH is quite secure, it's too lucrative a target, so it will always pose a risk.
What do you use in place of it?
A keyboard and a display, aka "the console". For example when using one's laptop or sitting at their stationary PC.
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#176Earlier quoted context omitted.
Theo de Raadt made an, I think, cogent observation about this bug and how to prevent similar ones: no signal handler should call any function that isn't a signal-safe syscall. The rationale is that, over time, it's too way easy for any transitive call (where it's not always clear that it can be reached in signal context) to pick up some call that isn't async signal safe.
I'm kind of surprised advocating calling any syscall other than signal to add the handler back again. It's been a long time since I looked at example code, but back in the mid 90s, everything I saw (and so informed my habits) just set a flag, listened to the signal again if it was something like SIGUSR1 and then you'd pick up the flag on the next iteration of your main loop. Maybe that's also because I think of a sig…
This isn't the case for OpenSSH but because a lot of environments (essentially all managed runtimes) actually do this transparently for you when you register a signal "handler" it might be that less people are aware that actual signal handlers require a ton of care. On the other hand "you can't even call strcmp in a signal handler or you'll randomly corrupt program state" used to be a favorite among practicing C lawyers.
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#177From the report: > Finally, if sshd cannot be updated or recompiled, this signal handler race condition can be fixed by simply setting LoginGraceTime to 0 in the configuration file. This makes sshd vulnerable to a denial of service (the exhaustion of all MaxStartups connections), but it makes it safe from the remote code execution presented in this advisory. Setting 'LoginGraceTime 0' in sshd_config file seems to mit…
Hang on, https://www.man7.org/linux/man-pages/man5/sshd_config.5.html says > If the value is 0, there is no time limit. Isn't that worse ?
If you can turn on TCP keepalive for the server connections, you would still have a timeout, even if it's typically 2 hours. Then if someone wants to keep connections open and run you out of sockets and processes, they've got to keep sockets open on their end (but they might run a less expensive userspace tcp)
You can belt and suspenders with an external tool that watches for sshd in pre-auth for your real timeout and kills it or drops the tcp connection [1] (which will make the sshd exit in a more orderly fashion)
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#178Why are we all still running an ssh server written in an unsafe language in 2024?
Because nobody has written an sshd in a memory safe language with the same track record of safety as OpenSSH. I personally wouldn't trust a new sshd for a few years at least.
There’s a Rust library that implements most of the protocol, but I’ve not found a “drop in replacement” using said library yet.
Might actually make for a fun side project to build a SSH server using that library and see how well it performs.
Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
#179And who was notoriously not exploitable? The ones hiding sshd behind port knocks. And fail2ban: would work too. And a restrictive firewall: would help too. I don't use port-knocking but I really just don't get all those saying: "It's security theater" . We had not one but two major OpenSSH "near fiasco" (this RCE and the xz lib thing) that were both rendered unusable for attackers by using port knocking. To me port-k…
Port-knocking is a PITA in theory and even worse in real world : people do not have time nor the will to do wild invocations before getting job done. Unless you are talking about your own personal use-case, in which case, feel free to follow your deepest wishes Firewall is a joke, too. Who can manage hundreds and thousands of even-changing IP ? Nobody. Again: I'm not talking about your personal use-case (yet I enjoy…
I’ve written a few toy port knocking implementations, and doing it right is hard.
If your connections crap and there’s packet loss, some of the sequence may be lost.
Avoiding replay attacks is another whole problem - you want the sequence to change based on a shared secret and time or something similar (eg: TOTP to agree the sequence).
Then you have to consider things like NAT…