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

11–20 of 347 posts

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

#11

Post by vesinisa »

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

Even if it means the attack takes 10x as long, it doesn't seem to be limited by bandwidth, only time. Might not take long before the bots appear that try to automatically exploit this on scale.

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

#12

Post by jesprenj »

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

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

#13

Post by djmdjm »

morsch wrote: post #7
djmdjm wrote: post #3

OpenSSH release notes: https://www.openssh.com/txt/release-9.8 Minimal patches for those can't/don't want to upgrade: https://marc.info/?l=oss-security&m=171982317624594&w=2

> Exploitation on 64-bit systems is believed to be possible but has not been demonstrated at this time.

I'm confident that someone will make a workable exploit against 64-bit systems.

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

#14

Post by letters90 »

> 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

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

#15

Post by rfmoz »

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 mitigate the issue.

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

#16

Post by fanf2 »

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 code inside signal handlers, which becomes unsafe when ported to other systems. They would have avoided this bug if they had done one of their refactoring sweeps to minimize the amount of code in signal handlers, according to the usual wisdom and common unix code guidelines.

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

#17

Post by simonjgreen »

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

For servers you have control over, as an emergency bandaid, sure. Assumes you are not on an embedded system though like a router.

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

#18

Post by letters90 »

simonjgreen wrote: post #17
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

For servers you have control over, as an emergency bandaid, sure. Assumes you are not on an embedded system though like a router.

I didn't consider embedded, probably the biggest target for this.

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

#19

Post by nubinetwork »

cperciva wrote: post #10
nubinetwork wrote: post #5

I haven't seen an increase of ssh traffic yet, but the alert only went out a couple hours ago... hopefully distros will ship the patches quickly.

This is the sort of bug which pre-announcement coordination is designed for. Anyone who doesn't have patches ready was either forgotten (I've seen a few instances of "I thought you were going to tell them!") or isn't on the ball.

Gentoo announced it at the same time as qualys, but they're currently trying to backport and bump users to a patched version. https://bugs.gentoo.org/935271

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

#20

Post by FiloSottile »

Interestingly, the RCE fix was "smuggled" in public almost a month ago.

    When PerSourcePenalties are enabled, sshd(8) will monitor the exit
    status of its child pre-auth session processes. Through the exit
    status, it can observe situations where the session did not
    authenticate as expected. These conditions include when the client
    repeatedly attempted authentication unsucessfully (possibly indicating
    an attack against one or more accounts, e.g. password guessing), or
    when client behaviour caused sshd to crash (possibly indicating
    attempts to exploit sshd).

    When such a condition is observed, sshd will record a penalty of some
    duration (e.g. 30 seconds) against the client's address.
https://github.com/openssh/openssh-portable/commit/81c1099d2...

It's not really a reversable patch that gives anything away to attackers: it changes the binary architecture in a way that has the side-effect of removing the specific vulnerability and also mitigates the whole exploit class, if I understand it correctly. Very clever.

Post reply on HN