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

71–80 of 347 posts

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

#71

Post by paulmd »

letters90 wrote: post #14

> 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). Mitigate by using fail2ban? Nice to see that Ubuntu isn't affected at all

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

AMD to the rescue - fortunately they decided to leave the take-a-way and prefetch-type-3 vulnerability unpatched, and continue to recommend that the KPTI mitigations be disabled by default due to performance costs. This breaks ASLR on all these systems, so these systems can be exploited in a much shorter time ;)

AMD’s handling of these issues is WONTFIX, despite (contrary to their assertion) the latter even providing actual kernel data leakage at a higher rate than meltdown itself…

(This one they’ve outright pulled down their security bulletin on) https://pcper.com/2020/03/amd-comments-on-take-a-way-vulnera...

(This one remains unpatched in the third variant with prefetch+TLB) https://www.amd.com/en/resources/product-security/bulletin/a...

edit: there is a third now building on the first one with an unpatched vulnerabilities in all zen1/zen2 as well… so this one is WONTFIX too it seems, like most of the defects TU Graz has turned up.

https://www.tomshardware.com/news/amd-cachewarp-vulnerabilit...

Seriously I don’t know why the community just tolerates these defenses being known-broken on the most popular brand of CPUs within the enthusiast market, while allowing them to knowingly disable the defense that’s already implemented that would prevent this leakage. Is defense-in-depth not a thing anymore?

Nobody in the world would ever tell you to explicitly turn off ASLR on an intel system that is exposed to untrusted attackers… yet that’s exactly the spec AMD continues to recommend and everyone goes along without a peep. It’s literally a kernel option that is already running and tested and hardens you against ASLR leakage.

The “it’s only metadata” is so tired. Metadata is more important than regular data, in many cases. We kill people, convict people, control all our security and access control via metadata. Like yeah it’s just your ASLR layouts leaking, what’s the worst that could happen? And I mean real data goes too in several of these exploits too, but that’s not a big deal either… not like those ssh keys are important, right?

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

#72

Post by fmbb »

nj5rq wrote: post #48

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. Saving the day once again.

“async-signal-safer”

Just this morning was the first time I read the words MT-Safe, AS-Safe, AC-Safe. But I did not know there were “safer” functions as well.

Is there also a “safest” syslog?

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

#73

Post by pjmlp »

apache101 wrote: post #59
nj5rq wrote: post #48

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. Saving the day once again.

Theo and team way ahead of their time like always.

Not always,

36C3 - A systematic evaluation of OpenBSD's mitigations

https://www.youtube.com/watch?v=3E9ga-CylWQ

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

#74

Post by cies »

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…

I use port knocking to keep my ssh logs clean. I dont think it adds security (I even brag about using it in public). It allows me to read ssh's logs without having to remove all the script kiddie login attempt spam.

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

#75

Post by OJFord »

fmbb wrote: post #72
nj5rq wrote: post #48

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. Saving the day once again.

“async-signal-safer” Just this morning was the first time I read the words MT-Safe, AS-Safe, AC-Safe. But I did not know there were “safer” functions as well. Is there also a “safest” syslog?

For a word like 'safe', or at least in CS, I would assume that the 'safe' one actually is 'safest'; that 'safer' is ehh it's not safe but it's an improvement on the unsafe one. It's safer.

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

#76

Post by rs_rs_rs_rs_rs »

ulrikrasmussen wrote: post #22
letters90 wrote: post #14

> 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). Mitigate by using fail2ban? Nice to see that Ubuntu isn't affected at all

Where do you see that Ubuntu isn't affected?

>Side note: we discovered that Ubuntu 24.04 does not re-randomize the ASLR of its sshd children (it is randomized only once, at boot time); we tracked this down to the patch below, which turns off sshd's rexec_flag. This is generally a bad idea, but in the particular case of this signal handler race condition, it prevents sshd from being exploitable: the syslog() inside the SIGALRM handler does not call any of the malloc functions, because it is never the very first call to syslog().

No mention on 22.04 yet.

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

#77

Post by zshrc »

pjmlp wrote: post #73
apache101 wrote: post #59

Earlier quoted context omitted.

Theo and team way ahead of their time like always.

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

Not always, but they make it their goal to be.

Code standards are very strict in OpenBSD and security is always a primary thought...

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

#78

Post by daneel_w »

pjmlp wrote: post #73
apache101 wrote: post #59

Earlier quoted context omitted.

Theo and team way ahead of their time like always.

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.

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

#79

Post by ralferoo »

OJFord wrote: post #75
fmbb wrote: post #72

Earlier quoted context omitted.

“async-signal-safer” Just this morning was the first time I read the words MT-Safe, AS-Safe, AC-Safe. But I did not know there were “safer” functions as well. Is there also a “safest” syslog?

For a word like 'safe', or at least in CS, I would assume that the 'safe' one actually is 'safest'; that 'safer' is ehh it's not safe but it's an improvement on the unsafe one. It's saf er .

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

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

#80

Post by abofh »

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 works if you have to ssh to your servers, there are many solutions that obviate even that, and leave you with no open ports, but a fully manageable server. I'm guilty of ssm in aws, but the principal applies - the cattle phone home, you only have to call pets.
Post reply on HN