Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


RCE in OpenSSH
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

RCE in OpenSSH

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.

«1

Comments

  • Carlin0Carlin0 Member
    edited July 1

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

    Already fixed this morning

  • davidedavide Member
    edited 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.

  • Carlin0Carlin0 Member
    Thanked by 1davide
  • kaitkait Member

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

  • LeviLevi Member

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

  • DPDP Administrator, The Domain Guy

    @kait said:

    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 :smiley:

  • edited July 1

    @DP said:

    @kait said:

    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 :smiley:

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

    Thanked by 1DP
  • 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.

  • raindog308raindog308 Administrator, Veteran

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

  • DPDP Administrator, The Domain Guy

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

  • cpsdcpsd Member

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

  • @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

    Thanked by 1DataRecovery
  • skorousskorous Member

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

    Thanked by 1Maounique
  • raindog308raindog308 Administrator, Veteran

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

    2600 or Joe Camel?

  • DPDP Administrator, The Domain Guy

    @raindog308 said:

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

    2600 or Joe Camel?

    2600, of course :smiley:

  • raindog308raindog308 Administrator, Veteran

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

  • farsighterfarsighter Member
    edited 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__lukast__ Member

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

    Thanked by 1totally_not_banned
  • farsighterfarsighter Member
    edited July 1

    @lukast__ said:
    Already posted

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

    Thanked by 1lukast__
  • jperkinsjperkins Member
    edited 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

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

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

  • maverickmaverick Member

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

    Thanked by 1DataRecovery
  • lukast__lukast__ Member

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

    Thanked by 1DataRecovery
  • raindog308raindog308 Administrator, Veteran

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

  • hostdarehostdare Member, Patron Provider

    almalinux,rockylinux, centos affected ?

  • coolicecoolice Member

    @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

  • CloudHopperCloudHopper Member
    edited July 2

    .

  • emghemgh Member, BF Ambassador

    @totally_not_banned said:

    @DP said:

    @kait said:

    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 :smiley:

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

    Phrack = phat + rack ?

Sign In or Register to comment.