Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

qualys.com

Post reply on HN
Print view View original

91–100 of 347 posts

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

#91

Post by yjftsjthsd-h »

rfmoz wrote: post #15

From 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?

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

#92

Post by ralferoo »

djmdjm wrote: post #28
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…

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 signal like an interrupt, and something you want to get done as soon as possible to not cause any stalls to the main program.

I notice that nowadays signalfd() looks like a much better solution to the signal problem, but I've never tried using it. I think I'll give it a go in my next project.

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

#93

Post by kazinator »

philodeon wrote: post #87
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 ludicrous security measure compared to the combination of: * configuring sshd to only listen over a Wireguard tunnel under your control ( or letting something like Tailscale set up the tunnel for you) * switching to ssh certificate authn instead of passwords or keys

Does Wireguard work in such a way that there is no trace of its existence to an unauthorized contacting entity?

I used port knocking for a while many years ago, but it was just too fiddly and flaky. I would run the port knocking program, and see the port not open or close.

If I were to use a similar solution today (for whatever reason), I'd probably go for web knocking.

In my case, I didn't see it as a security measure, but just as a way to cut the crap out of sshd logs. Log monitoring and banning does a reasonable job of reducing the crap.

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

#94

Post by throw0101b »

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…

> […] rendered unusable for attackers by using port knocking.

Port knocking renders SSH unusable: I'm not going to tell my users "do this magic network incantation before running ssh". They want to open a terminal and simply run ssh.

See the A in the CIA triad, as well as U in the Parkerian hexad.

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

#96

Post by School-Cotton »

nubinetwork wrote: post #25
rlpb wrote: post #24

Earlier quoted context omitted.

There are many wannabe security researchers who find issues that are definitely not exploitable, and then demand CVE numbers and other forms of recognition or even a bounty. For example, there might be an app that crashes when accepting malformed trusted input, but the nature of the app is that it's never intended to and realistically never will be exposed to an adversary. In most people's eyes, these are simply bugs…

> There are many wannabe security researchers who find issues that are definitely not exploitable, and then demand CVE numbers and other forms of recognition or even a bounty I believe this has happened to curl several times recently.

It happens constantly to any startup with a security@ email address.

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

#97

Post by DEADMINCE »

mmsc wrote: post #68
udev4096 wrote: post #52

Earlier quoted context omitted.

How is local privilege escalation relevant here? Fail2ban should be able to block the RCE

How is it not? If fail2ban isn't going to blocklist localhost, then it isn't a mitigation for this vulnerability because RCE implies LPE.

People are generally not trying to get root via an SSH RCE over localhost. That's going to be a pretty small sample of people that applies to.

But, sure, in that case fail2ban won't mitigate, but that's pretty damn obviously implied. For 99% of people and situations, it will.

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

#98

Post by DEADMINCE »

TacticalCoder wrote: post #65
Piskvorrr wrote: post #51

Earlier quoted context omitted.

It should trigger fail2ban, that's for sure. Alerting is useless, with the volume of automated exploits attempted.

> It should trigger fail2ban, that's for sure. But people here are going to explain that fail2ban is security theater...

Can you link to any comment in this thread of someone actually claiming that?

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

#99

Post by DEADMINCE »

p51-remorse wrote: post #82
ralferoo wrote: post #79

Earlier quoted context omitted.

Similarly, safest is normal English means not completely safe, but more safe than the other options. So safe > safest > safer > safe-ish > unsafe.

Wait, that seems backwards to me as a native English speaker. The superlative version feels more safe. Safest > Safe > (…)

Nah. If something is 'safe', it's safe, period. If something is safest is, it's only the best of the available options and not necessarily 'safe'.

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

#100

Post by DEADMINCE »

daneel_w wrote: post #78
pjmlp wrote: post #73

Earlier quoted context omitted.

Not always, 36C3 - A systematic evaluation of OpenBSD's mitigations https://www.youtube.com/watch?v=3E9ga-CylWQ

Wouldn't a good systematic evaluation need (or at least benefit from) a few actual working exploits/PoCs? I keep asking this as a long-time OpenBSD user who is genuinely interested in seeing it done, but so far everyone who has said "it's flawed" also reserved themselves the convenience of not having to prove their point in a practical sense.

> Wouldn't a good systematic evaluation need (or at least benefit from) a few actual working exploits/PoCs?

Sure, see any of the previous exploits for sshd, or any other software shipped in the OpenBSD default install.

> I keep asking this as a long-time OpenBSD user who is genuinely interested in seeing it done, but so far everyone who has said "it's flawed" also reserved themselves the convenience of not having to prove their point in a practical sense.

The point is they have very little in the way of containing attackers and restricting what they can. Until pledge and unveil, almost all their focus in on eliminating bugs which hey, great, but let's have a little more in case you miss a bug and someone breaks in, eh?

An insecure dockerized webserver protected with SELinux is safer than Apache on a default OpenBSD install.

Post reply on HN