If you're dealing with Linux servers, or you have an active OpenSSH Server on your desktop, you may want to look into regreSSHion.
Made public by Qualys today, who you might remember from the vulnerabilities in the GNU C Library they announced earlier this year. Their latest discovery is actually a regression, but quite a serious one. Tagged as CVE-2024-6387 it's "a signal handler race condition in OpenSSH’s server (sshd), allows unauthenticated remote code execution (RCE) as root on glibc-based Linux systems".
Their research showed it's a regression of CVE-2006-5051, which was reported in 2006 but then introduced again as an issue going back to October 2020 (OpenSSH 8.5p1). Woops.
Here's what they said about:
This vulnerability, if exploited, could lead to full system compromise where an attacker can execute arbitrary code with the highest privileges, resulting in a complete system takeover, installation of malware, data manipulation, and the creation of backdoors for persistent access. It could facilitate network propagation, allowing attackers to use a compromised system as a foothold to traverse and exploit other vulnerable systems within the organization.
Moreover, gaining root access would enable attackers to bypass critical security mechanisms such as firewalls, intrusion detection systems, and logging mechanisms, further obscuring their activities. This could also result in significant data breaches and leakage, giving attackers access to all data stored on the system, including sensitive or proprietary information that could be stolen or publicly disclosed.
This vulnerability is challenging to exploit due to its remote race condition nature, requiring multiple attempts for a successful attack. This can cause memory corruption and necessitate overcoming Address Space Layout Randomization (ASLR). Advancements in deep learning may significantly increase the exploitation rate, potentially providing attackers with a substantial advantage in leveraging such security flaws.
See all in their announcement.
See e.g. here: https://archlinux.org/news/the-sshd-service-needs-to-be-restarted-after-upgrading-to-openssh-98p1/
Quoting: BlackBloodRumYou may also as a temporary fix mitigate the issue by setting "LoginGraceTime 0" in your SSH configuration."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."
https://ubuntu.com/security/CVE-2024-6387
Quoting: TarosYup, but it's a temporary measure until you can properly patch things, after all. A DoS is better than remote code execution in my opinion.Quoting: BlackBloodRumYou may also as a temporary fix mitigate the issue by setting "LoginGraceTime 0" in your SSH configuration."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."
https://ubuntu.com/security/CVE-2024-6387
Relevant info for RHEL folks:
https://access.redhat.com/security/cve/cve-2024-6387
Quoting: birdipNote that you should restart your openssh daemon right after updating the package. Otherwise it is possible that you are locked out from your server!
See e.g. here: https://archlinux.org/news/the-sshd-service-needs-to-be-restarted-after-upgrading-to-openssh-98p1/
Doesn't Arch do that automatically? DEB based distributions all restart the running demon when the package is installed/upgraded.
See more from me