RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems • Hacker News Board

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#161

Post by JackSlateur » Mon, Jul 01, 2024, 2:57 PM UTC

TacticalCoder wrote: post #62

And 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 connecting to my server through 4G, whereever I am)

Fail2ban, on the other hand, is nice: every systems that relies on some known secret benefits from an anti-bruteforce mechanism. Also, and this is important: fail2ban is quick to deploy, and not a PITA for users. Good stuff.

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#162

Post by creshal » Mon, Jul 01, 2024, 3:01 PM UTC

INTPenis wrote: post #30

fanf2 wrote: post #16

It’s also worth reading the release notes https://www.openssh.com/releasenotes.html This is actually an interesting variant of a signal race bug. The vulnerability report says, “OpenBSD is notably not vulnerable, because its SIGALRM handler calls syslog_r(), an async-signal-safer version of syslog() that was invented by OpenBSD in 2001.” So a signal-safety mitigation encouraged OpenBSD developers to put non-trivial c…

So it's very likely that some young sysadmin or intern that will have to patch for this vuln was not even born when OpenBSD implemented the solution.

n>=1, one of our juniors is indeed younger than the OpenBSD fix and dealing with this bug.

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#163

Post by creshal » Mon, Jul 01, 2024, 3:03 PM UTC

metadat wrote: post #157

wiredfool wrote: post #53

Earlier quoted context omitted.

Looks like Focal (20.04) isn't on an affected version. Jammy (22.04) looks like it is.

What about, uh, 18.04? Edit: 18.04 Bionic is unaffected, the ssh version is 7.6 which is too old.

If you have extended support: Just update (if it's not so old that it's not even affected in the first place)

If you don't have extended support: You're vulnerable to worse, easier to exploit bugs :)

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#164

Post by JeremyNT » Mon, Jul 01, 2024, 3:05 PM UTC

JackSlateur wrote: post #156

megous wrote: post #2

In our experiments, it takes ~10,000 tries on average to win this race condition, so ~3-4 hours with 100 connections (MaxStartups) accepted per 120 seconds (LoginGraceTime). Ultimately, it takes ~6-8 hours on average to obtain a remote root shell, because we can only guess the glibc's address correctly half of the time (because of ASLR). MaxStartups default is 10

Default is 100: https://github.com/openssh/openssh-portable/blob/master/serv...

The config option called MaxStartups accepts a tuple to set 3 associated variables in the code. It wasn't clear to me which value people were referring to.

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#165

Post by guerby » Mon, Jul 01, 2024, 3:06 PM UTC

gavinhoward wrote: post #141

As someone who does unspeakable, but safe, things in signal handlers, I can confirm that it is easy to stray off the path of async-signal-safety.

I agree and I'm surprised OpenSSH developpers did not remove the use of SIGALRM and replace it by select/poll timer and explicitly managed future event list. Likely more portable and safe by default from this class of bugs that has bitten ssh code more than one time now...

Defensive programming tells us to minize code in signal handlers and the safest is to avoid using the signal at all when possible :).

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#166

Post by sneak » Mon, Jul 01, 2024, 3:07 PM UTC

Why are we all still running an ssh server written in an unsafe language in 2024?

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#167

Post by chasil » Mon, Jul 01, 2024, 3:08 PM UTC

zshrc wrote: post #50

djernie wrote: post #46

RedHat put an 8.1 score on it: https://access.redhat.com/security/cve/cve-2024-6387

Doesn’t affect RHEL7 or RHEL8.

Or RHEL9.

  $ rpm -q openssh
  openssh-8.7p1-38.0.1.el9.x86_64

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#168

Post by [deleted] » Mon, Jul 01, 2024, 3:10 PM UTC

sneak wrote: post #166

Why are we all still running an ssh server written in an unsafe language in 2024?

[deleted]

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#169

Post by bauruine » Mon, Jul 01, 2024, 3:12 PM UTC

sneak wrote: post #166

Why 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.

Re: RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

#170

Post by daneel_w » Mon, Jul 01, 2024, 3:21 PM UTC

DEADMINCE wrote: post #126

daneel_w wrote: post #115

Earlier quoted context omitted.

> Sure, see any of the previous exploits for sshd, or any other software shipped in the OpenBSD default install. Would you like to point to one that successfully utilizes a weakness in OpenBSD itself , which is the topic and implied statement of the video, rather than a weakness in some application running under the superuser? Just to underline, I'm not interested in discussing the hows and whys of containing arbitra…

> Would you like to point to one that successfully utilizes a weakness in OpenBSD itself, which is the topic and implied statement of the video, rather than a weakness in some application running under the superuser? I'm sorry, what? What kind of nonsense distinction is this? Are you trying to very disingenuously try and claim only kernel exploits count as attacks against OpenBSD? Why the hell wouldn't a webserver ze…

> I'm sorry, what? What kind of nonsense distinction is this?

> Are you trying to very disingenuously try and claim only kernel exploits count as attacks against OpenBSD?

Not at all. I clearly underlined that I'm not looking for cases fitting that specific scenario. The only moving of goalposts is entirely on your behalf by very disingenously misrepresenting my question in a poor attempt to try make your answer or whatever point fit. And on top of that, the tasteless pretending to be baffled...