RCE in OpenSSH

MallocVoidstar · July 1

https://www.openssh.com/releasenotes.html

OpenSSH 9.8/9.8p1 (2024-07-01)

This release contains fixes for two security problems, one critical and one minor.
1) Race condition in sshd(8)
A critical vulnerability in sshd(8) was present in Portable OpenSSH versions between 8.5p1 and 9.7p1 (inclusive) that may allow arbitrary code execution with root privileges.
Successful exploitation has been demonstrated on 32-bit Linux/glibc systems with ASLR. Under lab conditions, the attack requires on average 6-8 hours of continuous connections up to the maximum the server will accept. Exploitation on 64-bit systems is believed to be possible but has not been demonstrated at this time. It's likely that these attacks will be improved upon.
Exploitation on non-glibc systems is conceivable but has not been examined. Systems that lack ASLR or users of downstream Linux distributions that have modified OpenSSH to disable per-connection ASLR re-randomisation (yes - this is a thing, no - we don't understand why) may potentially have an easier path to exploitation. OpenBSD is not vulnerable.

Qualys blog: https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server
Qualys technical analysis: https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt

The version in Debian 12 was vulnerable, so update your shit.

M66B · July 1

Less technical info: https://thehackernews.com/2024/07/new-openssh-vulnerability-could-lead-to.html

Carlin0 · July 1

@MallocVoidstar said:
The version in Debian 12 was vulnerable, so update your shit.

Already fixed this morning

davide · July 1

@Carlin0 said:
Already fixed this morning

With what? Debian repos don't have a safe version of openssh-server.

But that these guys call malloc in a signal handler is beyond me.

Edit: 1:9.2p1-2+deb12u3, this specific version is patched with the fix.

Carlin0 · July 1

@davide sign up → [email protected]

kait · July 1

@MallocVoidstar said: Qualys technical analysis: https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt

This is a super good read, love that its just text, makes it so much easier to read.

Levi · July 1

@davide said:

@Carlin0 said:
Already fixed this morning

With what? Debian repos don't have a safe version of openssh-server.

But that these guys call malloc in a signal handler is beyond me.

Edit: 1:9.2p1-2+deb12u3, this specific version is patched with the fix.

Could you care to provide MD5 and SHA1 checksums for said version?

DP · July 1

@kait said:

@MallocVoidstar said: Qualys technical analysis: https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt

This is a super good read, love that its just text, makes it so much easier to read.

Reminds me of the good old e-zine days

totally_not_banned · July 1

@DP said:

@kait said:

@MallocVoidstar said: Qualys technical analysis: https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt

This is a super good read, love that its just text, makes it so much easier to read.

Reminds me of the good old e-zine days

Come on it's just been 3 years since the last issue of Phrack

TheGreatOakley · July 1

All the servers were running bullseye! Once being behind was better. I guess now it's a good time to update to the latest version, lmao.

raindog308 · July 1

@totally_not_banned said: Come on it's just been 3 years since the last issue of Phrack

DP · July 1

@raindog308 said:

@totally_not_banned said: Come on it's just been 3 years since the last issue of Phrack

LOL, that just reminded me of Lamo (RIP).

cpsd · July 1

I don't know what is portable openssh so perhaps our systems are not affected, right ?

MallocVoidstar · July 1

@cpsd said:
I don't know what is portable openssh so perhaps our systems are not affected, right ?

Systems which were vulnerable: Debian 12, RHEL 9, Ubuntu 22.04/23.10/24.04*

* released patches but 24.04 at least is apparently not actually vulnerable according to Qualys

for OSes based on one of these, assume vulnerable

for other OSes I guess just check their bug trackers or something

skorous · July 1

@cpsd said:
I don't know what is portable openssh so perhaps our systems are not affected, right ?

In this context "portable" means for systems other than BSD I believe.

raindog308 · July 1

@DP said: LOL, that just reminded me of Lamo (RIP).

2600 or Joe Camel?

DP · July 1

@raindog308 said:

@DP said: LOL, that just reminded me of Lamo (RIP).

2600 or Joe Camel?

2600, of course

raindog308 · July 1

@DP said: 2600, of course

I haven't read it in years. Amusingly there is a small family grocery near me that has a small magazine rack of bridal, sports, home, and car mags. For some reason, their distributor also sends them 2600 when it comes out, so I glance through it there. I haven't found a need to actually buy it in some time...and I think when I did buy it when I was younger I was just trying to be cool.

farsighter · July 1

In the past 24 hours a significant vulnerability in OpenSSH has been uncovered, potentially allowing full root access to internet servers through the glibc library of the Linux operating system.

The vulnerability, dubbed "regreSSHion," enables an attacker to take control of a server and execute commands granting complete access to the computer during a secure remote login process.

Initial estimates suggest that over 14 million internet servers may be exposed to this vulnerability, classified as CVE-2024-6387.

Addressing this threat would require updating millions of computers, restarting them, and updating factories and computerized equipment.

Long article:
https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server

Technical information:
https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt

lukast__ · July 1

Already posted, https://lowendtalk.com/discussion/195903/rce-in-openssh (and hopefully already upgraded everywhere).

farsighter · July 1

@lukast__ said:
Already posted

Ah. ‏So this one can be deleted or merged as a comment there

jperkins · July 2

https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt

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

so would fail2ban limit this ?

we have targeted virtual machines only, not bare-metal servers, on a
mostly stable network link (~10ms packet jitter);

so would the timing be that much harder to race with a true remote network ?

we have started to work on an amd64 exploit, which is much harder
because of the stronger ASLR.

Eventually, we devised the following technique (which seems to be
specific to the i386 glibc -- the amd64 glibc does not seem to use
_vtable_offset at all)

With a heap corruption as a primitive, two FILE structures malloc()ated
in the heap, and 21 fixed bits in the glibc's addresses, we believe that
this signal handler race condition is exploitable on amd64 (probably not
in ~6-8 hours, but hopefully in less than a week). Only time will tell.

so are there very many people using modern OS like debian 12 on 32 bit architecture ?

if you prohibit root login or prohibit root password logins does it matter ?

It doesnt get much worse than remote ssh exploit. How big of a deal is this one anyway.
yea I already updated

totally_not_banned · July 2

@jperkins said:
https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt

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

so would fail2ban limit this ?

I'm not sure about fail2ban but sshguard probably would. As far as i know it counts every connection that doesn't result in a successful login as a fail with default of 3 fails = 10 minute block. I guess that would slow things down a bit.

we have targeted virtual machines only, not bare-metal servers, on a
mostly stable network link (~10ms packet jitter);

so would the timing be that much harder to race with a true remote network ?

Well, maybe you should just try rooting a couple of your neighbors at [insert-favorite-provider-here] and then move on to random boxes in China for science

we have started to work on an amd64 exploit, which is much harder
because of the stronger ASLR.

Eventually, we devised the following technique (which seems to be
specific to the i386 glibc -- the amd64 glibc does not seem to use
_vtable_offset at all)

With a heap corruption as a primitive, two FILE structures malloc()ated
in the heap, and 21 fixed bits in the glibc's addresses, we believe that
this signal handler race condition is exploitable on amd64 (probably not
in ~6-8 hours, but hopefully in less than a week). Only time will tell.

so are there very many people using modern OS like debian 12 on 32 bit architecture ?

It's probably quite rare. Some time ago one would occasionally see 32bit systems used to preserve RAM on very, very tiny VPS but most of them are gone these days and so is probably this practice.

if you prohibit root login or prohibit root password logins does it matter ?

Probably not really relevant as it isn't skipping the password but rather injects code into the SSH process. It's still possible that being able to enter a password is somehow relevant to the exploit though.

yea I already updated

Same.

DataRecovery · July 2

@MallocVoidstar said:
Systems which were vulnerable: Debian 12, RHEL 9, Ubuntu 22.04/23.10/24.04*

A quick question from a lazy retard (/me):

Older Debians (10/11) and CentOSes (like 7 and 6, yes, six) aren't affected, right?

Sorry if the question is stupid, the week is really busy due to the people going on vacations, had zero time to read about all this.

maverick · July 2

@DataRecovery said: A quick question from a lazy retard (/me):

Older Debians (10/11) and CentOSes (like 7 and 6, yes, six) aren't affected, right?

Informative page: https://security-tracker.debian.org/tracker/CVE-2024-6387

And yes, even if Debian 10 is no longer supported, it is NOT vulnerable.

lukast__ · July 2

@DataRecovery said:

@MallocVoidstar said:
Systems which were vulnerable: Debian 12, RHEL 9, Ubuntu 22.04/23.10/24.04*

A quick question from a lazy retard (/me):

Older Debians (10/11) and CentOSes (like 7 and 6, yes, six) aren't affected, right?

Sorry if the question is stupid, the week is really busy due to the people going on vacations, had zero time to read about all this.

Debian 10/11 seems to be not vulnerable.
Not vulnerable are: 4.4p1 <= OpenSSH < 8.5p1
Debian 10 has 7.9p1, Debian 11 has 8.4p1.

But upgrading those systems may nevertheless be a good idea...

raindog308 · July 2

@farsighter said: Addressing this threat would require updating millions of computers, restarting them, and updating factories and computerized equipment.

You mean like every other CVE ever issued since the dawn of time?

hostdare · July 2

almalinux,rockylinux, centos affected ?

coolice · July 2

@hostdare said:
almalinux,rockylinux, centos affected ?

Version nine 9 (ssh server 8.7) Amla / CloudLinux - I do not have the othe OS but should be the same if they are build from RH Enterprise source (which is the purpouse to exist)

Version 8 is 8.0 so not

CloudHopper · July 2

emgh · July 2

@totally_not_banned said:

@DP said:

@kait said:

@MallocVoidstar said: Qualys technical analysis: https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt

This is a super good read, love that its just text, makes it so much easier to read.

Reminds me of the good old e-zine days

Come on it's just been 3 years since the last issue of Phrack

Phrack = phat + rack ?

Howdy, Stranger!

Categories

In this Discussion

RCE in OpenSSH

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

RCE in OpenSSH

Comments