CVE-2024-6387 (OpenSSH)
CVE-2024-6387 (OpenSSH)
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
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
-
- Master
- Posts: 105
- Joined: Sat Apr 15, 2023 11:53 pm
- Reputation: 0
- Status: Offline
Re: CVE-2024-6387 (OpenSSH)
With intruder detection currently broken in VSI OpenSSH, I'm uncertain.
https://forum.vmssoftware.com/viewtopic.php?f=30&t=8969
https://forum.vmssoftware.com/viewtopic.php?f=30&t=8969
-
- 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)
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".
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.
-
- Active Contributor
- Posts: 33
- Joined: Fri Nov 17, 2023 11:27 am
- Reputation: 1
- Status: Offline
Re: CVE-2024-6387 (OpenSSH)
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
[1] https://www.theregister.com/2024/07/01/ ... /?td=rt-3a
-
- VSI Expert
- Valued Contributor
- Posts: 63
- Joined: Tue May 09, 2023 7:57 am
- Reputation: 1
- Status: Offline
Re: CVE-2024-6387 (OpenSSH)
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.
Re: CVE-2024-6387 (OpenSSH)
For Linux systems a workaround is to set LoginGraceTime to 0:
Source: https://www.qualys.com/2024/07/01/cve-2 ... stract.com
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