CVE-2024-6387 (OpenSSH)

Everything related to the OpenVMS security model, system access, system and data protection, and security auditing.
Post Reply

Topic author
joukj
Master
Posts: 239
Joined: Thu Aug 27, 2020 5:50 am
Reputation: 0
Status: Offline

CVE-2024-6387 (OpenSSH)

Post by joukj » Tue Jul 02, 2024 8:32 am

Hi

It seems that certain versions of OpenSSH (inluding the one on OpenVMS) contain a vulnerability (CVS-2024-6387) by which an attacker can run arbitrary code. It seems that in "theory" you need a lot of trials before success. So in principle our "intruder detection" should protect us. Is that true? Or do we need a newer version of OpenSSH.

Jouk


pocketprobe
Master
Posts: 105
Joined: Sat Apr 15, 2023 11:53 pm
Reputation: 0
Status: Offline

Re: CVE-2024-6387 (OpenSSH)

Post by pocketprobe » Tue Jul 02, 2024 10:13 am

With intruder detection currently broken in VSI OpenSSH, I'm uncertain.
https://forum.vmssoftware.com/viewtopic.php?f=30&t=8969

User avatar

arne_v
Senior Member
Posts: 524
Joined: Fri Apr 17, 2020 7:31 pm
Reputation: 0
Location: Rhode Island, USA
Status: Offline
Contact:

Re: CVE-2024-6387 (OpenSSH)

Post by arne_v » Tue Jul 02, 2024 1:30 pm

At least according to some sources the CVE only impacts systems where openssh is using glibc.

If that is correct then it is not likely that VMS will have the same vulnerability.

Added in 5 minutes 22 seconds:
BTW I am not sure that I agree with the vulnerability score of 8.3 - as I read the description then a simple user timeout triggers a signal that end up calling some non signal safe code. No doubt that it is a bug in the code. But exploiting it for RCE and not just DoS seems let us call it "very non trivial".
Last edited by arne_v on Tue Jul 02, 2024 7:03 pm, edited 2 times in total.
Arne
arne@vajhoej.dk
VMS user since 1986


craigberry
Active Contributor
Posts: 33
Joined: Fri Nov 17, 2023 11:27 am
Reputation: 1
Status: Offline

Re: CVE-2024-6387 (OpenSSH)

Post by craigberry » Tue Jul 02, 2024 9:31 pm

OpenBSD doesn't have the problem because: "From 2001, OpenBSD's SIGALRM handler calls syslog_r() instead [of syslog()] – a safer version of syslog() and as such isn't affected by regreSSHion."[1] I don't know what's in the SIGALRM handler on VMS, but I doubt there are any calls to syslog().

[1] https://www.theregister.com/2024/07/01/ ... /?td=rt-3a


dgordon
VSI Expert
Valued Contributor
Posts: 63
Joined: Tue May 09, 2023 7:57 am
Reputation: 1
Status: Offline

Re: CVE-2024-6387 (OpenSSH)

Post by dgordon » Wed Jul 03, 2024 8:27 am

I brought this thread to the attention of the OpenSSH team. Initial belief in engineering is that this is not an issue on VMS but we're looking into the implementation specifics to solidify that opinion.
Executive Vice President of InfoServer Engineering at VSI.

User avatar

arne_v
Senior Member
Posts: 524
Joined: Fri Apr 17, 2020 7:31 pm
Reputation: 0
Location: Rhode Island, USA
Status: Offline
Contact:

Re: CVE-2024-6387 (OpenSSH)

Post by arne_v » Wed Jul 03, 2024 11:23 am

Arne
arne@vajhoej.dk
VMS user since 1986


raymii
Contributor
Posts: 24
Joined: Fri Dec 04, 2020 2:32 am
Reputation: 0
Status: Offline

Re: CVE-2024-6387 (OpenSSH)

Post by raymii » Fri Jul 05, 2024 12:24 pm

For Linux systems a workaround is to set LoginGraceTime to 0:
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.


Source: https://www.qualys.com/2024/07/01/cve-2 ... stract.com

Post Reply