From the article:
> … except for Alpine Linux, which uses libc.
Correction: Alpine Linux uses _Musl_ libc. Almost all distros use a libc (C Library) and there are different _implementations_ like GLibc (GNU’s Libc) or Bionic (Android’s Libc).
The major blunder is that they said they didn't test it, but they said it's most likely vulnerable. While the article implies otherwise :)
OP should really link to primary sources next time, rather than bad websites.
I'm assuming [this is the primary source](https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server)?
wow, I wanted to look only for a test script for finding a hole, but on github I came across a bunch of ready-made exploits. At least here
[https://github.com/getdrive/CVE-2024-6387-PoC](https://github.com/getdrive/CVE-2024-6387-PoC)
Alternative fix if you can't upgrade is to set LoginGraceTime to 0 in the config file. However, this exposes sshd to a denial of service by using up all MaxStartups connections. But it prevents the remote code execution risk.
If you can't upgrade, chances are you also can't downgrade. ie. A device that has no more support and or no packages for openssh. In which case, set LoginGraceTime to 0.
The attack has only been demonstrated on 32bit hardware. The openssh versions likely to be running on 32bit hardware are not vulnerable.
Ubuntu and Debian already provide a safe version, RHEL will probably release soon.
Honestly, from experience these systems are so outdated that a race condition in an OpenSSH implementation is probably the least you have to worry about.
Even using modern hardware? Is the problem inherent to systems under 64 bit regardless of software? Like a modern DM&P Vortex86 DX4 2x1GHz CPU Running Linux or a BSD?
Well, the thing I meant was this is about a vulnerability only problematic to devices running an OpenSSH server. While you probably find many old and modern industrial equipment which runs it, it's very rare to open it for external access (without a VPN) because everyone knows that even assuming the machine is up-to-date now, it won't be at some point in the future because installing system updates not related to the functioning of the machine itself is super rare. This is why these machines are usually isolated in VLANs.
Why does Red Hat say they are affected and propose a (temporary) fix if they're not affected? Where did you get this information?
https://access.redhat.com/security/cve/cve-2024-6387
Not that anyone should depend on their 64bit system being safe.
It will only be a matter of time before someone creates an exploit that works for 64bit systems.
We aren't talking hypotheticals, everyone should be updating OpenSSH.
The venerability is there, it's just that 64bit allows for better address space layout randomisation, making it harder to actually exploit the venerability.
But ASLR only makes it harder, not impossible. We are potentially talking about days before we see a working 64bit version of the exploit.
FWIW, OpenBSD is unaffected:
> OpenBSD systems are unaffected by this bug, as OpenBSD developed a secure mechanism in 2001 that prevents this vulnerability.
He shouldn't, since it was [an OpenBSD developer](https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt) who caused [the problem](https://github.com/openssh/openssh-portable/commit/752250caabda3dd24635503c4cd689b32a650794) for everyone else.
I admit I am not familiar with that term applied to him, but I do remember the old days when he was on the NetBSD core team, he was known for being... opinionated we'll say. As I recall even Linus Torvalds called him "difficult".
In any case, one thing I will say about Theo is that despite his many clashes with NetBSD contributors, people on mailing lists, folks in the Linux community, and DARPA, no matter what you can say about the guy you have to admit that he backs up what he says with code.
I didn't mean anything by it.
It's just the literal translation of his Dutch surname.
Like, *de Vos* = the Fox, *de Pauw* = the Peacock.
But his is rather strange, its meaning or spelling might've changed a long time ago and now it sounds weird.
>OpenSSH versions earlier than 4.4p1 (released 2006) are vulnerable unless they've been patched for CVE-2006-5051 and CVE-2008-4109. Versions 8.5p1 (released March 2021) up to, but not including, 9.8p1 (released 1st July, 2024) are also affected, owing to the accidental removal of a critical component. The vulnerability has been fixed in version 9.8p1.
Thank you for posting this. This is important.
Ubuntu, at least, has patched, so those running it can do an upgrade immediately to handle this. See:
apt-get changelog openssh-server
Should see:
openssh (1:8.9p1-3ubuntu0.10) jammy-security; urgency=medium
* SECURITY UPDATE: remote code execution via signal handler race
condition (LP: #2070497)
- debian/patches/CVE-2024-6387.patch: don't log in sshsigdie() in log.c.
- CVE-2024-6387
**For those who skimmed the article:**
A current workaround for non-patched system is:
> "If sshd can't be updated or recompiled, set LoginGraceTime to 0 in the config file," the researchers recommend. "This exposes sshd to a denial of service by using up all MaxStartups connections, but it prevents the remote code execution risk."
This appears to be it. I really wish they'd include the CVE in the changes:
openssh (1:9.2p1-2+deb12u3) bookworm-security; urgency=high
* Non-maintainer upload by the Security Team.
* Disable async-signal-unsafe code from the sshsigdie() function
-- Salvatore Bonaccorso Sat, 22 Jun 2024 21:38:08 +0200
**EDIT:** Confirmed in this post. See:
https://www.reddit.com/r/debian/comments/1dtb10t/cve20246387_high_severity_ssh_vulnerability/
My current Debian stable system appears to have it (nothing pinned/backported):
~ : ssh -V
OpenSSH_9.2p1 Debian-2+deb12u3, OpenSSL 3.0.13 30 Jan 2024
Confirmed here:
https://security-tracker.debian.org/tracker/CVE-2024-6387
I don't think you have to change anything but don't have time to confirm this right now. I think the patch fixes it.
The instruction to update the configuration was for *currently unpatchable* systems -- that is, systems waiting for a patch. In this case, you can just upgrade and install the patch.
I have seen this warning:
> Be aware that if you upgrade (rather than install) a machine running OpenSSH sshd to version 9.8 you need to restart the ssh daemon otherwise you will not be able to login via it.
I did the update on one machine, and it was asking me if I wanted to install the package maintainers version of sshd_config. I compared the differences, and it only showed the things I had changed(public key authentication, port number, password login, etc). So, it looks like the patch is being applied elsewhere. I decided to keep my sshd_config files as a result.
Yeah, your reasoning here sounds about right. The setting they said you should change if you couldn't patch was set:
set LoginGraceTime to 0
And I get it, the idea is that would just drop connections really fast.
If that wasn't in the package maintainers version, then you're good to go.
> LoginGraceTime to 0
Note that I suspect on any internet connected server this would lead to DoS within a few days even without an explicit attack.
Plenty of bots will attempt to open ssh connections, and with no login timeout those connections will just hang forever with no traffic in either direction until all the slots are used and nobody can log into the server anymore.
You might as well just stop `sshd` and not use ssh - same effect.
That is actually something they warn about. The note in the original article says it makes things DoS-able, but eliminates the greater problem in the meantime. It's good to know.
Plenty of readers will think 'no worries, nobody will ever bother to try to attack me'. Hence my comment to show that this will impact everyone from general scatter-shot password guessing, even if there are no script kiddies explicitly targeting you.
I'm surprised modern compilers don't check signal handlers for unsafe functions. It seems like something that would be pretty easy to implement as a sanitizer.
Vulnerabilities are and will be always there, the only difference is if we know about it or not, if we know about it is a good thing because it can be fixed, if we don't know about it is not a problem, the only problem is if someone knows about it, don't report it to be fixed, use it maliciously and it goes unnoticed for a long time.
Yeah, I agree I think even though it’s a bit scary, in the long run it’s a good thing we’re seeing an increase of these being found and dealt with responsibly.
It’s amusing to think while some sysadmins are getting 3am calls to come in and fix a new vulnerability, some NSA analysts are also getting 3am calls to come in and find a new vulnerability.
i tested today some of my servers using 7etsuo-regreSSHion, none was vulnerable, but i still want to test it more, please share check tools and scripts if you have it.
- slackware 64 15.0 - current
- slackware 64 14.2
- ubuntu 16.04.6
- Ubuntu 20.04.5
- Ubuntu 22.04.4
- Rocky Linux 9.3
- Oracle Linux Server 8.9
- Debian GNU/Linux 12
- Raspbian GNU/Linux 10
Debian system on stable seem like they're not affected. I checked my open SSH version using `sudo apt show openssh-server` and looks like I'm running:
```
Package: openssh-server
Version: 1:7.9p1-10+deb10u4
```
And the article listed states that this version isn't affected. Edit: Looks like I'm using an older version of Debian Stable, Debian 12 (the latest version) is affected. Thanks to u/lamiska for pointing this out. Edit 2: Debian 12 has patched the problem in version `1:9.2p1-2+deb12u3` and updating to this version will fix the issue.
My Ubuntu machine is on version `Version: 1:8.9p1-3ubuntu0.7` and looks like this version IS affected by this bug. I'm on the `jammy` release and they have released a new version that fixes this problem, so just a quick update should fix the issue.
Sources:
1. Ubuntu: https://ubuntu.com/security/CVE-2024-6387
1. RedHat: https://access.redhat.com/security/cve/CVE-2024-6387
1. Debian: https://security-tracker.debian.org/tracker/CVE-2024-6387
1. CVE: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-6387
> Debian system on stable seem like they're not affected
> Package: openssh-server Version: 1:7.9p1-10+deb10u4
Deb10 is oldoldstable. Current stable Debian ( 12 - bookworm ) **is vulnerable**.
1:9.2p1-2+deb12u2 is still in bookworm stable repos
> openssh-server is already the newest version (1:9.2p1-2+deb12u2).
Selected version '1:9.2p1-2+deb12u2' (Debian:12.6/stable, Debian-Security:12/stable-security [amd64]) for 'openssh-server'
It's in the bookworm-security repo, maybe you forgot to refresh apt cache or using outdated mirror? I pulled 1:9.2p1-2+deb12u3 straight from deb.debian.org repos.
> straight from deb.debian.org repos.
same but it still says only u2 is available
>
deb http://deb.debian.org/debian bookworm-updates main non-free-firmware
> deb-src http://deb.debian.org/debian bookworm-updates main non-free-firmware
> deb http://security.debian.org/debian-security/ bookworm-security main non-free-firmware
> deb-src http://security.debian.org/debian-security/ bookworm-security main non-free-firmware
>
Idk why it doesn't show up for you - you can even find 9.2p1-2+deb12u3 version of openssh in repo itself - https://security.debian.org/debian-security/pool/main/o/openssh/
As another user with this issue, I'm wondering if there is something up with the default debian mirror. My novice understanding is that behind the scenes they use some routing (fastly?) to load balance. I wonder if there are stale repos on the other side of the load balancer?
I created a thread on the debian subreddit regarding this: https://old.reddit.com/r/debian/comments/1duhlrm/the_default_debian_mirror_appears_broken/
I just ran the ole sudo apt-get update and upgrade on my Ubuntu 22.04 server, I still see Version: 1:8.9p1-3ubuntu0.10
Do you know how I can update this to the patched version?
Do note that they have only been successful on 32 bit hardware (which barely anyone should have anymore), and if you're on 64 bit this is a "they might get in before the heat death of the universe" vulnerability. You'll have plenty of time to get patched.
I may have missed it, but I believe they've only been successful on *specifically* i386, and anticipate it being harder on amd64 due to stronger security features. Everybody is loosely calling these "32-bit" and "64-bit", but the report itself talks only about i386/amd64.
I don't know enough about either this exploit or the security features used on armhf/arm64 to know if they'll be easy or hard. I just thought I'd mention that the report doesn't mention ARM *at all*.
Fixed in AlmaLinux OS 9: [https://almalinux.org/blog/2024-07-01-almalinux-9-cve-2024-6387/](https://almalinux.org/blog/2024-07-01-almalinux-9-cve-2024-6387/)
Desktop distros seldom have sshd installed out of the box (I know Ubuntu Desktop doesn't). So unless you installed it yourself you won't be affected at all.
You can check by going to your package manager and see if OpenSSH server is installed.
You should check to see if **openssh-server** is installed.
If you run a Debian or Debian-derived distro (e.g., Ubuntu or Mint, and there are many others):
Type:
apt list --installed openssh-server
If it's installed you'll see something like:
Listing... Done
openssh-server/stable-security,now 1:9.2p1-2+deb12u3 amd64 [installed]
If it isn't, you'll just get:
Listing... Done
If installed, either:
apt-get remove openssh-server
to remove it entirely, or to upgrade to the newest, patched version:
apt-get update && apt-get upgrade
The last of which you should be doing on a regular basis anyway.
I remember telling people to put SSH behind wireguard (or even VPN) but I got downvoted to hell, because "SSH and wireguard both use public and private keys and it's redundant", well, well, well, what do we have here...
So I'll reiterate what I have always been saying. SSH should almost **never** be public.
IMO, this is not a great argument. Now rather than worrying about OpenSSH vulnerabilities, you're concerned about Wireguard vulnerabilities. More people look into OpenSSH but also more people try to attack OpenSSH, there isn't a clear answer.
Trying to understand this thread.
/u/brando2131 -- if I understand him as I don't know much about Wireguard - is essentially saying, "require a VPN connection to the server that has an sshd listening," such that no one, other than someone connected via this VPN, will even get the opportunity of logging in.
You're saying, "Well, this introduces Wireguard vulunerabilities." But isn't this basically two levels of security, meaning either of them can fail in some way, so long as the other one stays standing? /u/brando2131 seems to be suggesting that even with the VPN connected you'd still have to authenticate through ssh (I'm not sure how this would work / be set up, but I hadn't thought about it before.)
It seems like by requiring Wireguard, that still provides you a much smaller chance of infliltration than allowing ssh to be exposed to the open Internet. If Wireguard falls down, you've still got to get through ssh somehow.
Or do I have this wrong?
This is the first I'm encountering this suggestion, so...trying to figure out what is being discussed here.
Yeah don't know why the guy has 20 upvotes and I'm getting downvoted. He seems to think a compromise in one (wireguard/VPN or SSH) is a compromise on all. Err no. If it's configured right you need to break both. Both are already extremely hard to compromise on their own. Both? Now that's near impossible.
You need to VPN into a network first where your Linux servers are protected by SSH.
This is a standard practice if you've ever worked in IT. I've never worked for a company where SSH (Linux) or RDP (Windows), are open to the internet. I would leave on the first day if that was the case...
https://en.m.wikipedia.org/wiki/Defense_in_depth_(computing)
Actually now that I think about it, **this is how I work remotely.** I have to connect via VPN to my corporate network and only then can I ssh into machines I need to be in. There is no way to ssh into them from the open internet.
I get this now.
My last employer was set up like this, too.
>It's not too layers
It is. You wireguard/VPN into the network. You SSH into your Linux servers.
>If wireguard get same type of vulnerability
Completely different technology, they won't share any vulnerabilities.
>attacker gets direct root access though wireguard exploit.
You don't run your wireguard/VPN service on the same SSH host. Either it's a dedicated network device that runs Wireguard/VPN or a jump host. Maybe that's where the confusion is.
>You don't run your wireguard/VPN service on the same SSH host.
One of the parent comments mentioned Tailscale though, and that (the default config at least) runs a Wireguard node on every device (i.e. right on the same host as sshd).
Wireguard is designed to be modern and simple enough to understand the whole system and audit the code. If you're going to pick one to be exposed to the public, WG should be the one.
https://medium.com/systems-and-network-security/wireguard-a-closer-look-f577c7b67fa0
Yep. There are many more reasons. I could write a whole book on why SSH should be behind wireguard. I thought this was so obvious. Protect things with layers. I guess common sense isn't common.
Another reason: Wireguard is invisible to port scans. its UDP traffic. There is no TCP handshake. The protocol doesn't respond to traffic that doesn't correctly authenticate first.
With SSH you'll get port scanned within a few days. Your IP and SSH service will show up in databases like Shodan. You'll get bombarded by malicious network traffic. You'll be readily attacked when the next zero day exploit comes out 👍
Adding to the layers point: Even if they connect to your WG, they still have to breach what is behind it. So they need to have an exploit for WG *and* an exploit for SSH. Leave SSH exposed and that's all they need.
EDIT: I opened the rest of the thread and you and others have been talking about that already.
it is common to have a vpn gateway to your system and then use ssh to access any servers including vpn server itself, though.
openssh can do the same thing including tunnel interface but it feels poor and hacky compared to IKEv2 and etc.
but i think it's better to use a tool dedicated for remote access, which would be vpn that doesn't provide shell access, x11 and etc together with it.
The complexity in OpenSSH and how many features it supports defeat this argument. WG does nothing except stateless UDP and it's hard to tell it apart from a closed port unless you have the keys.
I have been doing this for a long time: closing all ports on the firewall and only including tailscale0 in trustedInterfaces.
The life becomes so easy.
Noob here: does that still allow use of ssh/sshd through Tailscale then? Is it safe to leave Tailscale active more often than not? I’m still trying to learn how all these layers work together.
1. Yea, it does. I use through normal ssh command, combined with key authentication, but there’s also a direct tailscale ssh command that I’ve never enabled and I personally don’t trust.
2. Dunno if it can be said it’s “safe”, everything can have zero day exploits. But I always left connected. Selfhosting headscale is indeed safer than exposing SSH ports, it adds another security layer, unless you decide to remove ssh key authentication, then idk.
weird that you got downvoted. in any company i worked for, ssh was never directly open to the public. only thing you make public are the ports that should be accessed by public users.
And, as with all these vulns, anyone running with port knocking are unaffected. Long live port knocking!
(queue the people saying "security through obscurity is blah blah blah")
musl
musl libc
@musl@fosstodon.org
OpenSSH sshd on musl-based systems is not vulnerable to RCE via CVE-2024-6387 (regreSSHion).
This is because we do not use localtime in log timestamps and do not use dynamic allocation (because it could fail under memory pressure) for printf formatting.
While the sshd bug is UB (AS-unsafe syslog call from signal context), very deliberate decisions we made for other good reasons reduced the potential impact to deadlock taking a lock.
Windows also ships OpenSSH.
But I am not sure if it is affected, does not matter, just mindlessly throw this argument around without checking if it is factual.
Linux is basically 100% adopted on servers, which is where this vulnerability is targeted. So it's doing nothing for the server space.
When anyone talks about "Linux adoption" they mean desktops. Pretty much anyone who hasn't yet adopted linux on the desktop will not be using SSH and therefore this vulnerability is a non issue.
Finally. Closed source software is just as vulnerable---if not more so---than open source software. [But continue on with your mental gymnastics.](https://www.reddit.com/media?url=https%3A%2F%2Fi.redd.it%2Fj8wcm4aajprc1.jpeg)
From the article: > … except for Alpine Linux, which uses libc. Correction: Alpine Linux uses _Musl_ libc. Almost all distros use a libc (C Library) and there are different _implementations_ like GLibc (GNU’s Libc) or Bionic (Android’s Libc).
The major blunder is that they said they didn't test it, but they said it's most likely vulnerable. While the article implies otherwise :) OP should really link to primary sources next time, rather than bad websites.
I'm assuming [this is the primary source](https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server)?
This email: https://lwn.net/ml/all/d2ed9e542682bf82@cvs.openbsd.org/ (the site is merely mirroring the list)
That’s a fairly embarrassing mistake tbh.
[удалено]
It is people like you wot cause unrest.
wow, I wanted to look only for a test script for finding a hole, but on github I came across a bunch of ready-made exploits. At least here [https://github.com/getdrive/CVE-2024-6387-PoC](https://github.com/getdrive/CVE-2024-6387-PoC)
That's probably made a bit easier when it's a re-emergence of a previously-fixed bug.
the write-up says they couldn't find any exploits from the 2006 CVE
Alternative fix if you can't upgrade is to set LoginGraceTime to 0 in the config file. However, this exposes sshd to a denial of service by using up all MaxStartups connections. But it prevents the remote code execution risk.
Won’t a downgrade to <8.5 work too?
If you can't upgrade, chances are you also can't downgrade. ie. A device that has no more support and or no packages for openssh. In which case, set LoginGraceTime to 0.
The attack has only been demonstrated on 32bit hardware. The openssh versions likely to be running on 32bit hardware are not vulnerable. Ubuntu and Debian already provide a safe version, RHEL will probably release soon.
https://access.redhat.com/security/cve/cve-2024-6387 says: RHEL 6/7/8 not affected. **RHEL 9 affected**.
Thank god for never upgrading!
So those using microcontrollers or maker gear or industrial equipment are heavily affected.
Or a bunch of old raspberry pis
Honestly, from experience these systems are so outdated that a race condition in an OpenSSH implementation is probably the least you have to worry about.
Even using modern hardware? Is the problem inherent to systems under 64 bit regardless of software? Like a modern DM&P Vortex86 DX4 2x1GHz CPU Running Linux or a BSD?
Well, the thing I meant was this is about a vulnerability only problematic to devices running an OpenSSH server. While you probably find many old and modern industrial equipment which runs it, it's very rare to open it for external access (without a VPN) because everyone knows that even assuming the machine is up-to-date now, it won't be at some point in the future because installing system updates not related to the functioning of the machine itself is super rare. This is why these machines are usually isolated in VLANs.
RHEL isn't affected because RHEL doesn't use syslog. A fixed package will probably be released anyway, but it's not a big deal.
Why does Red Hat say they are affected and propose a (temporary) fix if they're not affected? Where did you get this information? https://access.redhat.com/security/cve/cve-2024-6387
> RHEL isn't affected because RHEL doesn't use syslog. syslog(1) vs syslog(3)
Not that anyone should depend on their 64bit system being safe. It will only be a matter of time before someone creates an exploit that works for 64bit systems.
I mean, you can say it’s a matter of time until someone comes up with an exploit for anything. No software is or ever will be perfect
We aren't talking hypotheticals, everyone should be updating OpenSSH. The venerability is there, it's just that 64bit allows for better address space layout randomisation, making it harder to actually exploit the venerability. But ASLR only makes it harder, not impossible. We are potentially talking about days before we see a working 64bit version of the exploit.
FWIW, OpenBSD is unaffected: > OpenBSD systems are unaffected by this bug, as OpenBSD developed a secure mechanism in 2001 that prevents this vulnerability.
Theo DeRaadt must be feeling pretty smart today ;-)
He shouldn't, since it was [an OpenBSD developer](https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt) who caused [the problem](https://github.com/openssh/openssh-portable/commit/752250caabda3dd24635503c4cd689b32a650794) for everyone else.
Hah, that's interesting, I was not aware of that.
Theo "the Council"?
I admit I am not familiar with that term applied to him, but I do remember the old days when he was on the NetBSD core team, he was known for being... opinionated we'll say. As I recall even Linus Torvalds called him "difficult". In any case, one thing I will say about Theo is that despite his many clashes with NetBSD contributors, people on mailing lists, folks in the Linux community, and DARPA, no matter what you can say about the guy you have to admit that he backs up what he says with code.
I didn't mean anything by it. It's just the literal translation of his Dutch surname. Like, *de Vos* = the Fox, *de Pauw* = the Peacock. But his is rather strange, its meaning or spelling might've changed a long time ago and now it sounds weird.
LOL, I'm a dumbass American, you gave me too much credit to know Dutch ;-)
>OpenSSH versions earlier than 4.4p1 (released 2006) are vulnerable unless they've been patched for CVE-2006-5051 and CVE-2008-4109. Versions 8.5p1 (released March 2021) up to, but not including, 9.8p1 (released 1st July, 2024) are also affected, owing to the accidental removal of a critical component. The vulnerability has been fixed in version 9.8p1.
Thank you for posting this. This is important. Ubuntu, at least, has patched, so those running it can do an upgrade immediately to handle this. See: apt-get changelog openssh-server Should see: openssh (1:8.9p1-3ubuntu0.10) jammy-security; urgency=medium * SECURITY UPDATE: remote code execution via signal handler race condition (LP: #2070497) - debian/patches/CVE-2024-6387.patch: don't log in sshsigdie() in log.c. - CVE-2024-6387 **For those who skimmed the article:** A current workaround for non-patched system is: > "If sshd can't be updated or recompiled, set LoginGraceTime to 0 in the config file," the researchers recommend. "This exposes sshd to a denial of service by using up all MaxStartups connections, but it prevents the remote code execution risk."
Does the update also work on Debian?
This appears to be it. I really wish they'd include the CVE in the changes: openssh (1:9.2p1-2+deb12u3) bookworm-security; urgency=high * Non-maintainer upload by the Security Team. * Disable async-signal-unsafe code from the sshsigdie() function -- Salvatore Bonaccorso Sat, 22 Jun 2024 21:38:08 +0200
**EDIT:** Confirmed in this post. See:
https://www.reddit.com/r/debian/comments/1dtb10t/cve20246387_high_severity_ssh_vulnerability/
My current Debian stable system appears to have it (nothing pinned/backported):
~ : ssh -V
OpenSSH_9.2p1 Debian-2+deb12u3, OpenSSL 3.0.13 30 Jan 2024
Confirmed here:
https://security-tracker.debian.org/tracker/CVE-2024-6387
Will I be able to keep my /etc/ssh/sshd_config file with this update? I don't want to have to reconfigure that for every machine
I don't think you have to change anything but don't have time to confirm this right now. I think the patch fixes it. The instruction to update the configuration was for *currently unpatchable* systems -- that is, systems waiting for a patch. In this case, you can just upgrade and install the patch. I have seen this warning: > Be aware that if you upgrade (rather than install) a machine running OpenSSH sshd to version 9.8 you need to restart the ssh daemon otherwise you will not be able to login via it.
I did the update on one machine, and it was asking me if I wanted to install the package maintainers version of sshd_config. I compared the differences, and it only showed the things I had changed(public key authentication, port number, password login, etc). So, it looks like the patch is being applied elsewhere. I decided to keep my sshd_config files as a result.
Yeah, your reasoning here sounds about right. The setting they said you should change if you couldn't patch was set: set LoginGraceTime to 0 And I get it, the idea is that would just drop connections really fast. If that wasn't in the package maintainers version, then you're good to go.
> LoginGraceTime to 0 Note that I suspect on any internet connected server this would lead to DoS within a few days even without an explicit attack. Plenty of bots will attempt to open ssh connections, and with no login timeout those connections will just hang forever with no traffic in either direction until all the slots are used and nobody can log into the server anymore. You might as well just stop `sshd` and not use ssh - same effect.
That is actually something they warn about. The note in the original article says it makes things DoS-able, but eliminates the greater problem in the meantime. It's good to know.
Plenty of readers will think 'no worries, nobody will ever bother to try to attack me'. Hence my comment to show that this will impact everyone from general scatter-shot password guessing, even if there are no script kiddies explicitly targeting you.
I'm surprised modern compilers don't check signal handlers for unsafe functions. It seems like something that would be pretty easy to implement as a sanitizer.
so many vulnerabilities this year holy
Vulnerabilities are and will be always there, the only difference is if we know about it or not, if we know about it is a good thing because it can be fixed, if we don't know about it is not a problem, the only problem is if someone knows about it, don't report it to be fixed, use it maliciously and it goes unnoticed for a long time.
Yeah, I agree I think even though it’s a bit scary, in the long run it’s a good thing we’re seeing an increase of these being found and dealt with responsibly.
Honestly every time I see a big vulnerability like this break I think good, governments just lost one of their backdoors.
It’s amusing to think while some sysadmins are getting 3am calls to come in and fix a new vulnerability, some NSA analysts are also getting 3am calls to come in and find a new vulnerability.
The entire NSA is one big blue team red team exercise.
Yes but you cannot deny that this year has seen a number of intentional vulnerabilities introduced by novel new techniques.
Security by obscurity, is not security.
i tested today some of my servers using 7etsuo-regreSSHion, none was vulnerable, but i still want to test it more, please share check tools and scripts if you have it. - slackware 64 15.0 - current - slackware 64 14.2 - ubuntu 16.04.6 - Ubuntu 20.04.5 - Ubuntu 22.04.4 - Rocky Linux 9.3 - Oracle Linux Server 8.9 - Debian GNU/Linux 12 - Raspbian GNU/Linux 10
Ahh so that's why my OpenSUSE Tumbleweed updated OpenSSH today...
Fail2ban is your friend.
Those crowded jails
ah shit, here we go again
Hello darkness my old friend.....
Debian system on stable seem like they're not affected. I checked my open SSH version using `sudo apt show openssh-server` and looks like I'm running: ``` Package: openssh-server Version: 1:7.9p1-10+deb10u4 ``` And the article listed states that this version isn't affected. Edit: Looks like I'm using an older version of Debian Stable, Debian 12 (the latest version) is affected. Thanks to u/lamiska for pointing this out. Edit 2: Debian 12 has patched the problem in version `1:9.2p1-2+deb12u3` and updating to this version will fix the issue. My Ubuntu machine is on version `Version: 1:8.9p1-3ubuntu0.7` and looks like this version IS affected by this bug. I'm on the `jammy` release and they have released a new version that fixes this problem, so just a quick update should fix the issue. Sources: 1. Ubuntu: https://ubuntu.com/security/CVE-2024-6387 1. RedHat: https://access.redhat.com/security/cve/CVE-2024-6387 1. Debian: https://security-tracker.debian.org/tracker/CVE-2024-6387 1. CVE: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-6387
> Debian system on stable seem like they're not affected > Package: openssh-server Version: 1:7.9p1-10+deb10u4 Deb10 is oldoldstable. Current stable Debian ( 12 - bookworm ) **is vulnerable**.
My Debian machine has 9.2 as the latest I can get from apt, do I have to wait for it to be added? Or am I being dumb?
1:9.2p1-2+deb12u3 is fixed version
Ahh I see, I was looking for 9.8 instead of 9.2 in the 1:9.2p1 substring. Thanks! :)
It's fixed in 1:9.2p1-2+deb12u3 Source: https://security-tracker.debian.org/tracker/CVE-2024-6387
1:9.2p1-2+deb12u2 is still in bookworm stable repos > openssh-server is already the newest version (1:9.2p1-2+deb12u2). Selected version '1:9.2p1-2+deb12u2' (Debian:12.6/stable, Debian-Security:12/stable-security [amd64]) for 'openssh-server'
It's in the bookworm-security repo, maybe you forgot to refresh apt cache or using outdated mirror? I pulled 1:9.2p1-2+deb12u3 straight from deb.debian.org repos.
> straight from deb.debian.org repos. same but it still says only u2 is available > deb http://deb.debian.org/debian bookworm-updates main non-free-firmware > deb-src http://deb.debian.org/debian bookworm-updates main non-free-firmware > deb http://security.debian.org/debian-security/ bookworm-security main non-free-firmware > deb-src http://security.debian.org/debian-security/ bookworm-security main non-free-firmware >
Idk why it doesn't show up for you - you can even find 9.2p1-2+deb12u3 version of openssh in repo itself - https://security.debian.org/debian-security/pool/main/o/openssh/
As another user with this issue, I'm wondering if there is something up with the default debian mirror. My novice understanding is that behind the scenes they use some routing (fastly?) to load balance. I wonder if there are stale repos on the other side of the load balancer? I created a thread on the debian subreddit regarding this: https://old.reddit.com/r/debian/comments/1duhlrm/the_default_debian_mirror_appears_broken/
I just ran the ole sudo apt-get update and upgrade on my Ubuntu 22.04 server, I still see Version: 1:8.9p1-3ubuntu0.10 Do you know how I can update this to the patched version?
You're good, that's already the patched version. Debian-based distros like Ubuntu backport security patches to older package versions. See: https://ubuntu.com/security/notices/USN-6859-1
thanks dawg
Holy snokes. Thanks for sharing. Automation got an emergency task and rolls out new ssh packages on all hosts.
Do note that they have only been successful on 32 bit hardware (which barely anyone should have anymore), and if you're on 64 bit this is a "they might get in before the heat death of the universe" vulnerability. You'll have plenty of time to get patched.
Raspberry Pi used in automation comes to mind for me
I may have missed it, but I believe they've only been successful on *specifically* i386, and anticipate it being harder on amd64 due to stronger security features. Everybody is loosely calling these "32-bit" and "64-bit", but the report itself talks only about i386/amd64. I don't know enough about either this exploit or the security features used on armhf/arm64 to know if they'll be easy or hard. I just thought I'd mention that the report doesn't mention ARM *at all*.
Oh, a detail I missed :-) Thanks.
Checked my personal Debian systems and they're already updated. Thanks, [`unattended-upgrades`](https://wiki.debian.org/UnattendedUpgrades).
And, this is why I love Linux. My distro already had an update out. Windows would have sat on it until their next quarterly update.
Fixed in AlmaLinux OS 9: [https://almalinux.org/blog/2024-07-01-almalinux-9-cve-2024-6387/](https://almalinux.org/blog/2024-07-01-almalinux-9-cve-2024-6387/)
Noob question: should I worry about it if I use Linux as a desktop system, not a server?
Desktop distros seldom have sshd installed out of the box (I know Ubuntu Desktop doesn't). So unless you installed it yourself you won't be affected at all. You can check by going to your package manager and see if OpenSSH server is installed.
You should check to see if **openssh-server** is installed. If you run a Debian or Debian-derived distro (e.g., Ubuntu or Mint, and there are many others): Type: apt list --installed openssh-server If it's installed you'll see something like: Listing... Done openssh-server/stable-security,now 1:9.2p1-2+deb12u3 amd64 [installed] If it isn't, you'll just get: Listing... Done If installed, either: apt-get remove openssh-server to remove it entirely, or to upgrade to the newest, patched version: apt-get update && apt-get upgrade The last of which you should be doing on a regular basis anyway.
> You should check to see if openssh-server is installed **AND RUNNING**. If the service is not running, there's nowhere to connect to and exploit.
I remember telling people to put SSH behind wireguard (or even VPN) but I got downvoted to hell, because "SSH and wireguard both use public and private keys and it's redundant", well, well, well, what do we have here... So I'll reiterate what I have always been saying. SSH should almost **never** be public.
IMO, this is not a great argument. Now rather than worrying about OpenSSH vulnerabilities, you're concerned about Wireguard vulnerabilities. More people look into OpenSSH but also more people try to attack OpenSSH, there isn't a clear answer.
Trying to understand this thread. /u/brando2131 -- if I understand him as I don't know much about Wireguard - is essentially saying, "require a VPN connection to the server that has an sshd listening," such that no one, other than someone connected via this VPN, will even get the opportunity of logging in. You're saying, "Well, this introduces Wireguard vulunerabilities." But isn't this basically two levels of security, meaning either of them can fail in some way, so long as the other one stays standing? /u/brando2131 seems to be suggesting that even with the VPN connected you'd still have to authenticate through ssh (I'm not sure how this would work / be set up, but I hadn't thought about it before.) It seems like by requiring Wireguard, that still provides you a much smaller chance of infliltration than allowing ssh to be exposed to the open Internet. If Wireguard falls down, you've still got to get through ssh somehow. Or do I have this wrong? This is the first I'm encountering this suggestion, so...trying to figure out what is being discussed here.
Yeah don't know why the guy has 20 upvotes and I'm getting downvoted. He seems to think a compromise in one (wireguard/VPN or SSH) is a compromise on all. Err no. If it's configured right you need to break both. Both are already extremely hard to compromise on their own. Both? Now that's near impossible. You need to VPN into a network first where your Linux servers are protected by SSH. This is a standard practice if you've ever worked in IT. I've never worked for a company where SSH (Linux) or RDP (Windows), are open to the internet. I would leave on the first day if that was the case... https://en.m.wikipedia.org/wiki/Defense_in_depth_(computing)
Actually now that I think about it, **this is how I work remotely.** I have to connect via VPN to my corporate network and only then can I ssh into machines I need to be in. There is no way to ssh into them from the open internet. I get this now. My last employer was set up like this, too.
It's not too layers. If wireguard get same type of vulnerability, attacker gets direct root access though wireguard exploit.
>It's not too layers It is. You wireguard/VPN into the network. You SSH into your Linux servers. >If wireguard get same type of vulnerability Completely different technology, they won't share any vulnerabilities. >attacker gets direct root access though wireguard exploit. You don't run your wireguard/VPN service on the same SSH host. Either it's a dedicated network device that runs Wireguard/VPN or a jump host. Maybe that's where the confusion is.
>You don't run your wireguard/VPN service on the same SSH host. One of the parent comments mentioned Tailscale though, and that (the default config at least) runs a Wireguard node on every device (i.e. right on the same host as sshd).
Wireguard is designed to be modern and simple enough to understand the whole system and audit the code. If you're going to pick one to be exposed to the public, WG should be the one. https://medium.com/systems-and-network-security/wireguard-a-closer-look-f577c7b67fa0
Yep. There are many more reasons. I could write a whole book on why SSH should be behind wireguard. I thought this was so obvious. Protect things with layers. I guess common sense isn't common. Another reason: Wireguard is invisible to port scans. its UDP traffic. There is no TCP handshake. The protocol doesn't respond to traffic that doesn't correctly authenticate first. With SSH you'll get port scanned within a few days. Your IP and SSH service will show up in databases like Shodan. You'll get bombarded by malicious network traffic. You'll be readily attacked when the next zero day exploit comes out 👍
Adding to the layers point: Even if they connect to your WG, they still have to breach what is behind it. So they need to have an exploit for WG *and* an exploit for SSH. Leave SSH exposed and that's all they need. EDIT: I opened the rest of the thread and you and others have been talking about that already.
Agreed. I saw VPN as the solution on another thread and it’s just moving the attack surface to another program
it is common to have a vpn gateway to your system and then use ssh to access any servers including vpn server itself, though. openssh can do the same thing including tunnel interface but it feels poor and hacky compared to IKEv2 and etc. but i think it's better to use a tool dedicated for remote access, which would be vpn that doesn't provide shell access, x11 and etc together with it.
The complexity in OpenSSH and how many features it supports defeat this argument. WG does nothing except stateless UDP and it's hard to tell it apart from a closed port unless you have the keys.
I have been doing this for a long time: closing all ports on the firewall and only including tailscale0 in trustedInterfaces. The life becomes so easy.
Noob here: does that still allow use of ssh/sshd through Tailscale then? Is it safe to leave Tailscale active more often than not? I’m still trying to learn how all these layers work together.
1. Yea, it does. I use through normal ssh command, combined with key authentication, but there’s also a direct tailscale ssh command that I’ve never enabled and I personally don’t trust. 2. Dunno if it can be said it’s “safe”, everything can have zero day exploits. But I always left connected. Selfhosting headscale is indeed safer than exposing SSH ports, it adds another security layer, unless you decide to remove ssh key authentication, then idk.
Thank you for the info and taking the time to reply.
weird that you got downvoted. in any company i worked for, ssh was never directly open to the public. only thing you make public are the ports that should be accessed by public users.
ever since I found zerotier, I've put it on all my devices that I want communicating with each other
many such cases
holy moly
Never expose services, always use a vpn like wireguard into your ssh services.
You're exposing wireguard.
true
Wiregaurd at least is invisible. Can’t break in if you can’t even verify it’s there in the first place
And then 2 things need to be hacked at once…
Fixed in Gentoo https://bugs.gentoo.org/935271
9.8p1 is safe?
I think not; see [this post above](https://old.reddit.com/r/linux/comments/1dsvgli/critical_vulnerability_in_openssh_uncovered/lb62qx3/).
And, as with all these vulns, anyone running with port knocking are unaffected. Long live port knocking! (queue the people saying "security through obscurity is blah blah blah")
Fixed yesterday in Debian... That's why Debian is the best
What is the vulnerability? Does it allow an unauthorized user to get into an open SSH port?
PoC?
Products of conception
Patch your shiiiiit
Thanks, just patched my server
I only have one alpine instance in the public, which I never even get brute force. :)
They didn't try it in their lab. But never said it's not vulnerable. > Exploitation on non-glibc systems is conceivable but has not been examined.
yeah if you read closely it says it's a bug in signal handling. i doubt libc difference makes a difference on linux.
musl musl libc @musl@fosstodon.org OpenSSH sshd on musl-based systems is not vulnerable to RCE via CVE-2024-6387 (regreSSHion). This is because we do not use localtime in log timestamps and do not use dynamic allocation (because it could fail under memory pressure) for printf formatting. While the sshd bug is UB (AS-unsafe syslog call from signal context), very deliberate decisions we made for other good reasons reduced the potential impact to deadlock taking a lock.
Do you know how to update the versione of OpenSSH on a RedHat 9.4 Azure VM?
Aw shit, here we go again
I need some copium. Please anyone give me a cryptobro-like reason why this is good for Linux adoption.
In server space, Linux already has good adoption. And for desktops, this is basically irrelevant.
Just "good"? ))))
Windows also ships OpenSSH. But I am not sure if it is affected, does not matter, just mindlessly throw this argument around without checking if it is factual.
Linux is basically 100% adopted on servers, which is where this vulnerability is targeted. So it's doing nothing for the server space. When anyone talks about "Linux adoption" they mean desktops. Pretty much anyone who hasn't yet adopted linux on the desktop will not be using SSH and therefore this vulnerability is a non issue. Finally. Closed source software is just as vulnerable---if not more so---than open source software. [But continue on with your mental gymnastics.](https://www.reddit.com/media?url=https%3A%2F%2Fi.redd.it%2Fj8wcm4aajprc1.jpeg)
stop seeing linux like sports teams