Serious vulnerability fixed with OpenSSH 9.8

Security

www.openssh.com/txt/release-9.8

170

99%

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.

that's a slow ass exploit for lab conditions. I'm guessing fail2ban would avoid this risk

turdas

Also only demonstrated on i386, which has much worse ASLR than amd64.

FryBoyter

I also ask myself how widespread the use of portable versions of OpenSSH (https://www.openssh.com/portable.html) is. Because apparently it only affects these versions.

Edit: Apparently more often than I expected. In the PKGBUILD file of OpenSSH under Arch, for example, pkgver=9.8p1 is specified. And for OpenSUSE it is 9.6p1.

MSR1210

portable in this case just means "not openbsd". every linux/windows computer with openssh installed is using the "portable" version

you can tell its the portable because the version numbers ends in "p1", as in debian and arch

FryBoyter

Thanks for the information. I had also noticed in the meantime that the portable version is quite widespread. I have therefore just edited my post.

When I think of portable, I was probably thinking of the portable versions of a program under Windows.

confusedcrib

I found this Qualys blog to be especially obnoxious about providing very few technical details while half of the space is an advertisement for their vuln management tools. The technical details are meanwhile relegated to the .txt here: https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt

I'm also updating this: https://pulse.latio.tech/p/regresshion-cve-2024-6387-response

I'll try to update this comment with more details, but at a high level it seems like a very legitimate zero day for remote execution on OpenSSH (most public facing linux servers with port 22 open)

My thoughts: The likelihood on a real world exploit for this is mixed - on the one hand, if it’s targeted it can definitely work, on the other hand, it requires a lot of noisy traffic over a long(ish) period of time.

It appears that Ubuntu 22.04 and later are effected with patches available https://ubuntu.com/security/CVE-2024-6387

Mitigation:

Patch the effected OS (list below)
If you can’t patch, this is the mitigation from Canonical: Set LoginGraceTime to 0 in /etc/ssh/sshd_config. This makes sshd vulnerable to a denial of service (the exhaustion of all MaxStartups connections), but it makes it safe from this vulnerability.

Effected Ditros:

Ubuntu greater than 22.04 - https://ubuntu.com/security/CVE-2024-6387

RHEL 9 - https://access.redhat.com/security/cve/cve-2024-6387

SUSE - Evaluation in progress: https://www.suse.com/security/cve/CVE-2024-6387.html

AWS Linux - ALAS 2023 is pending fix, everything else is not vulnerable - https://explore.alas.aws.amazon.com/CVE-2024-6387.html

High level attack summary: While every version exploit in the paper was slightly different, an attacker might need around 10,000 attempts to successfully exploit the vulnerability, potentially gaining root access hours to a week depending on the concurrent connections that are available.

NaheemSays

The fedora link seems to be for something else?

confusedcrib

thank you, you're correct, updating

leonderbaertige_II

Seems to be CVE-2024-6387 for the curious.

JockstrapCummies

Longer write-up by Qualys on the exploit: https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt

MetaTrombonist

FWIW, the easiest mitigation is to set LoginGraceTime to 0 until a fix is available for your distro.

Icommentedtoday

Sure, but then you're vulnerable to DoS. Better than root RCE I guess

Ripdog

17h

Huh? Have any distros NOT patched this?!

If so, please don't run a server on that distro!

Rerbun

Not yet available in "apt" on Ubuntu and Debian afaik

Ripdog

So, in other words, patched.

I mean, let's not get technical here.

BinkReddit

FWIW, OpenBSD is unaffected:

OpenBSD systems are unaffected by this bug, as OpenBSD developed a secure mechanism in 2001 that prevents this vulnerability.

Grunskin

Haha love that qoute

User deleted comment

MarcBeard

Doas has cool advantages like being able to do Ctrl + c

But yea it's like comparing cve between SystemD and openrc one is very regularly odited the other is not

ITStril

Did anybody find an information about if fail2ban regex does trigger on the timeout?

S48GS

How/does it affect OpenWRT and non x86 architecture like arm/mips/ppc?

Kimcha87

OpenWRT is alpine and not glibc I believe. So it seems like it wouldn’t be affected.

Moderator removed comment

18h

08-24-2022

So, should I update? Running Debian 12 on the server and Arch Linux on everything else.

Ripdog

17h

I mean, you should always be applying updates anyway. There are always security updates coming down the pipeline, and most of them don't make headlines like this one.

08-24-2022

17h

Is apt upgrade and pacman -Syu enough for applying patches? Apparently I'm running 1:9.2p1-2+deb12u3, am I safe? Sorry for being clueless.

nou_spiro

Yes

mohammedbabelly

15h

Is there any package manager which supports the latest openssh 9.8 yet? I don’t wish to compile it from source manually

Elegant-Extension-18

11h

https://archlinux.org/packages/core/x86_64/openssh/

2 missing replies