OpenSSH vulnerability CVE-2024-6387

According to this Reddit thread, RHEL 6, 7, and 8 are ok, but 9 is affected.

https://www.reddit.com/r/sysadmin/comments/1dspa43/cve20246387_pretty_big_openssh_vuln_for_any_glibc/

We are aware. You have two options:

  • Mitigate the issue by setting LoginGraceTime to 0 (note this can lead to a DoS)
  • Install rocky-release-security and update openssh, as it contains a patch until RHEL releases it themselves

See for more information: cve-details

3 Likes

I don’t want to be careless and ask if my train of thought is maybe wrong. We have a SSH server with two factor authentication and fail2ban. Does the later not mitigate the issue?

fail2ban will definitely help by reducing the number of attempts an attacker can make.

Since this is a timing attack and it’s not (yet!) been demonstrated on a 64bit system, I would wait until RedHat patch. But that’s just me :slight_smile:

1 Like

Restricting SSH to only trusted IP’s will also help reduce it if not eliminate the risk completely until the patch is released by RH for the main distro openssh package.

I’m fairly certain fail2ban will not help without a matching expression for connection-closed to Timeout. Logging must be set verbosely enough in order to catch that message. Fail2ban must be configured to recognize it as a failed login.

2-factor does not mitigate it. I’m not certain, but it seems that fail2ban does not mitigate it, if the attack is done in a way to avoid creating a failed login before the timeout occurs. The exploit uses the timeout + log message of such, combined with bogus payloads for the authentication step.

Not sure if “error: kex_exchange_identification: Connection closed by remote host” is logged by the attack path or not; that could be something fail2ban can block on. Otherwise, yeah, just “connection closed” lines.

In my case I use IPTables to rate limit ssh attempts (I’ve not yet updated my external facing machines to RL9) just to stop brute force attacks. It’d also help prevent this new attack.

# SSH firewall rules - deny access to servers that make more than 5 connections
# in 60 seconds

IPT=/sbin/iptables

# Set this to "DROP" to drop packets, or REJECT to reject packets
DROP=REJECT

# Only log slowly so we don't fill up logs and overload the linode
$IPT -N ssh-drop
$IPT -A ssh-drop -m limit --limit 2/minute -j LOG --log-prefix "FIREWALL:SSH-DROPPED "
$IPT -A ssh-drop -j $DROP

# Set this to "ssh-drop" for logging, or $DROP to silently lock them out
DEST=ssh-drop

$IPT -A INPUT -p TCP --dport 22 --syn -m recent --name ssh --update --seconds 60 --hitcount 5 -j $DEST

$IPT -A INPUT -p TCP --dport 22 --syn -m recent --name ssh --set

Upstream released it now (openssh-8.7p1-38.el9_4.1)

2 Likes

With iptables deprecated, we’d need the equivalent for firewalld or nftables.

Wow , checking all informatio inside the world , what is happening with the OPENSSH service . anyway , is there any way to know who is going to launch first the patch …

selinux , iptables does not help with the situation ?

You do know that Rocky is based on RHEL right? That means we have what RHEL has. When RHEL has it, then official Rocky OpenSSH will also have it. Also, if you read above you will see from security SIG repo you could have upgraded OpenSSH and you would have already had the fix - since the Rocky team patched it before RHEL even patched the official package.

@nazunalika said:

Read first before commenting.

The iptables tool in Rocky 8 and 9 is a wrapper-translator that generates nftables rules. (some exotic rules may fail to translate.) There is even a script that reads stored iptables ruleset-file and prints equivalent nftables syntax. Therefore, you should be able to create at least a start for nftables.service.

Is this patch is released ? or do i need to use rocky security patch ?

You can dnf update at any time to get an updated openssh with the patch. Using the SIG/security package is not necessary.

I did this, and it shows nothing to update. But when i checked the ssh version it shows the date from november 22.

What do you see with:
dnf list openssh\*

The ‘date’ in sshd --version is not the build date of the software–it’s the upstream release date.

You have the latest version of openssh installed on your system. That is why it says there’s “Nothing to do”.

rpm -q --changelog openssh shows the package build information.

2 Likes

Thank for the clarification