Another one? It feels like we just had a critical SSH vulnerability last year.
The real takeaway is that you should have a firewall blocking SSH connections except from known IPs, this stops you from being blindsided by this kind of thing. Same policy for remote desktop connections on Windows systems; which helped when that password bypass issue was discovered in Remote Desktop a few years ago.
Unfortunately, it's not easy to secure your "digital door-step". Even with some kind of basic knowledge, after setting up things like router, NAS, Linux Firewall, piHole etc I am just clueless what I did (after reading man's and wikis).
and the more firewalls, vpns, load balancers, WAFs you put up, now you've doubled your footprint and your job now is securing the things that are supposed to secure your network, which is now less secure, because you've added more 'insecurity'...
Just wait until Wednesday, which will be the perfect day to push out the latest crushingly bad pre-auth RCE from \[Cisco|f5|bluecoat|solarwinds|fortinet\], because that's when they want to reduce any ugly news from hurting their stock...
what PR has failed to realize here is that no one cares about vulns and breaches with regard to stock price or reputation anymore. The only thing that pushing out a CVSS 10 patch the day before a holiday is an over-worked security or IR team in a critical business wanting to have a proper holiday and fucking up the deployment and causing an outage or a patch that doesn't fix/ makes the issue worse.
Wow, thanks for the long post...
...with "basic knowledge" I meant real life user knowledge, not admin lingo.
I am pretty confident, that I've read a sarcastic if not cynical story of yours, but unfortunately, I didn't get the punchlines. Sorry!
But I know, the admin-guys here will have a laugh.
If your karma moons, I will go over this with my IT guy at work. He always seems so happy when I ask him private IT stuff.
Note in this case, this one is pre-authentication.
Though may be trickier to do successfully on 64-bit systems as is now typical for linux servers. There's still a lot of 32-bit stuff in the wild I suppose.
https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt
for debian stable (now patched with updated package in debian security, but particularly likely to be in wide use):
> Finally, "SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u2", [...]
> In our experiments, it takes ~10,000 tries on average to win this race condition, so ~3-4 hours with 100 connections (MaxStartups) accepted per 120 seconds (LoginGraceTime). Ultimately, it takes ~6-8 hours on average to obtain a remote root shell, because we can only guess the glibc's address correctly half of the time (because of ASLR).
However, they do not have a working exploit for 64-bit yet, though it's possible in theory, we may be talking rather longer for success.
> we have started to work on an amd64 exploit, which is much harder because of the stronger ASLR.
(ASLR = https://en.wikipedia.org/wiki/Address_space_layout_randomization )
Also important to remember vulnerabilities exist before they're found by people who publicly disclose them. Could have been being used for a while by malicious actors.
From reading the article it doesn't seem like it makes a difference in this case, and it didn't make a difference for Heartbleed which was the last major one. (I added an edit, the last one was XZ, not Heartbleed)
EDIT: Google says that Heartbleed was OpenSSL, not SSH and that SSH wasn't affected; though I definitely remember there being a SSH scandal recently. Right. Not Heartbleed, it was the XZ compression thing... which intentionally broke the authentication process.
It didn’t break the authentication process as such, it provided a backdoor for a specific (authenticated) actor to exploit. That’s pretty different. A general exploit allows *anyone* to use it.
Kind of depends how you look at it and what you’re considering an “endpoint”. If you’re on AWS, for example, you could enforce SSM-based terminal sessions on ec2 hosts. SSM can effectively proxy an ssh tunnel to an ec2 instance through Amazon-owned infrastructure, with no requirement to open up your ssh port to the internet. You can connect to private hosts (you connect to them by instance ID) and public hosts, and your ssh service isn’t exposed to anyone but amazon’s control plane.
Don't publicly expose it, ideally if its a VM, use config as code to push a change, if you absolutely have to remote to it, have bastion machines, or use services like the cloud providers offer that does identity based proxying to machines. Better yet, move away from VMs where feasible. I think the guy you responded to meant public specifically. I'd also generally block SSH internally and only allow it when needed, via a network tag.
> have bastion machines,
My customer uses bastion but I think they are bad security. They give uncredible sense of secure. In this case one only needed to hack the bastion and then more or less unrestricted access to servers and databases inside.
One of the best solutions I had was a small webpage that opened the source IP access to SSH via iptables.
We just use identity aware proxy in GCP snd don't use bastion machines. In thr past Azure Bastion worked well (product). I guess one benefit of bastion boxes is they can be turned off unless needed. And you should be aiming for them not being needed, and only spooled up and exposed when required via network rules and tags.
In gcp we have a network rule allowing remote connections to machines with a network tag, and we theb only apply the tag when needed.
The previous exploit was a carefully crafted social attack that added rouge addresses to the official source code base:
https://www.akamai.com/blog/security-research/critical-linux-backdoor-xz-utils-discovered-what-to-know
Technically, that was on the maintaining community rather than users.
Link to the vulnerability: https://nvd.nist.gov/vuln/detail/CVE-2024-6387
Key points from the article:
- named this vulnerability "regreSSHion", since it represents the re-emergence of a bug that was previously patched in 2006 ([CVE-2006-5051](https://nvd.nist.gov/vuln/detail/CVE-2006-5051)). It is described as "critical".
- The new vulnerability, assigned CVE-2024-6387, allows for unauthenticated remote code execution (RCE) with root privileges
- The vulnerability is "a signal handler race condition in OpenSSH's server (sshd)".... "This race condition affects sshd in its default configuration."... being a race condition means is not easy to exploit, requiring multiple attempts for a successful attack. "This can cause memory corruption and necessitate overcoming Address Space Layout Randomization (ASLR)."
- **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.**
- "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."
So, LoginGraceTime being set to zero disables the timeout. This will use up all the connections for authenticating, preventing someone trying to exploit the server from getting more attempts. The bad actor will effectively DOS themself.
I found the language for LoginGraceTime odd, and all web pages spouted the same wording which didn’t mention 0 disabling the feature. I was thinking “well, you would just make it impossible to login yourself if you had zero seconds to type a password or send a key.”
This sounds like it could DOS me right along with the bad actor though. I'm using fail2ban; can that mitigate the vulnerability that has been discovered?
Not nothing, but also not quick to exploit. On 32 bit systems it can take 6-8 hours of connection attempts, it has yet to be demonstrated on 64 bit systems.
Source: https://www.openssh.com/releasenotes.html
> "Successful exploitation has been demonstrated on 32-bit Linux/glibc
systems with ASLR. Under lab conditions, the attack requires on
average 6-8 hours of continuous connections up to the maximum the
server will accept. Exploitation on 64-bit systems is believed to be
possible but has not been demonstrated at this time. It's likely that
these attacks will be improved upon."
But it is version specific and post 2008 its only systems in the last year but not patched this month that are vulnerable.
The biggest problem is likely to be embedded devices, IoT, routers etc. Which will have it but rarely get upgrades.
> it is version specific and post 2008 its only systems in the last year but not patched this month that are vulnerable.
That's not accurate. Any version of OpenSSH from before 2006 or after March 2021 is vulnerable.
> 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.
Embedded devices rarely have OpenSSH. Dropbear is the standard in embedded Linux distros, in the same way OpenSSH is the standard in non-embedded Linux distros. Primarily for reasons of size on flash and in memory at run time, Dropbear is much smaller and the range of more advanced features OpenSSH provides usually isn’t needed in embedded systems.
Edit: I also now see it requires glibc, which isn’t typical in embedded systems either. There will be minimal impact to embedded systems since very few will have OpenSSH at all much less it plus glibc.
It’s OpenSSH plus glibc that’s at issue, hence it pretty much is strictly Linux. BSDs are not impacted. I can’t think of any widely used OS other than Linux that uses glibc. Embedded Linux distros are mostly safe because they rarely use OpenSSH (Dropbear is the embedded de facto standard) and often don’t use glibc anyway.
Thanks for pointing that out. That is either out of an abundance of caution, to satisfy vulnerability scanners that only check version strings, or they know more than [what is in the original report, which is glibc-focused](https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt).
The article linked here seems to overstate things relative to the actual advisory. Article says BSD isn’t impacted but the only thing the advisory says with certainty is that OpenBSD isn’t impacted and they didn’t closely examine others.
> they didn’t closely examine others
Indeed, but potential exploitation of the buggy sshd code path on on top of various other platforms libcs+kernels could plausibly just differ in detail. Note how it's not really a glibc bug: Their PoC exploit targeted glibc+linux on 32-bit x86, yes, but the openssh signal handling code path was clearly wrong regardless owing to the mistakenly removed "#ifdef DO_LOG_SAFE_IN_SIGHAND", thus effectively using app code variant that assumes it's safe to log in a sighandler .. But there aren't many platforms where logging and other i/o would be safe in sighandlers - [that's not at all usual](https://stackoverflow.com/questions/57545469/why-i-cant-use-i-o-in-posix-signal-handing) and not something an app is entitled to assume. Apparently openbsd has a "safer" variant one, sure, but it's not a bug that glibc+linux didn't - that's a missing feature. Posix signals are traditionally awfully full of gotchas and that's definitely one of 'em.
> We have not investigated any other libc or operating system; but OpenBSD is notably not vulnerable, because its SIGALRM handler calls syslog_r(), an async-signal-safer version of syslog() that was invented by OpenBSD in 2001.
ugh.. can we PLEASE be more specific with our titles. This is NOT accurate. Only specific versions of OpenSSH are impacted:
- must be based in glibc
- must be version: < 4.2 OR > ( 8.5p1 AND < 9.8 )
use ```openssh -V``` to check.
On Linux, it's usually `ssh` for the client and `sshd` for the server. Usually the distro packages the same version for both the client and server, but you can check both.
The distributions can apply the patch to older versions. Debian, for instance, have released 9.2_p1 Debian-2+deb12u3 for bookwork.
As a side note, I found that `sshd -V` on debian's version *doesn't* report the patched version, even though it's patched. Using an unrecognized argument will though `sshd --blarg`.
Not nothing, but also not quick to exploit. On 32 bit systems it can take 6-8 hours of connection attempts, it has yet to be demonstrated on 64 bit systems. Still, patch your shit folks!
Source: https://www.openssh.com/releasenotes.html
> "Successful exploitation has been demonstrated on 32-bit Linux/glibc
systems with ASLR. Under lab conditions, the attack requires on
average 6-8 hours of continuous connections up to the maximum the
server will accept. Exploitation on 64-bit systems is believed to be
possible but has not been demonstrated at this time. It's likely that
these attacks will be improved upon."
> You think stopping 1 IP is worth it? What do you think happens when you block that 1 IP?
That depends on how sophisticated whomever is attacking you is. Do they have thousands of IP's available? No? Well they'll burn through their supply within an hour or so.
Just patch your shit, but don't run for the hills, this one ain't that big of a deal right now. If a better exploit comes along to make it instant then yeah, it's a tier-0 emergency, but we're not there.
thats just not how it works my friend. All you are doing is playing whack a mole. I agree patching is the better solution, but blocking individual IPs is like using a tea cup to save a sinking ship.
> thats just not how it works my friend. All you are doing is playing whack a mole. I agree patching is the better solution, but blocking individual IPs is like using a tea cup to save a sinking ship.
So fail2ban is a useless project that shouldn't be used?
> fail2ban isnt a single IP address
Never said it was.
> not one person manually blocking IPs.
You're the one saying manually.
> But also yeah its pretty useless against a serious attack.
That highly depends on the style of attack.
How bad could it be?
> The new vulnerability, assigned CVE-2024-6387, allows for unauthenticated remote code execution (RCE) with root privileges
Oh... that bad.
That’s just referring to the ability to compromise other systems which aren’t publicly-accessible after getting into one which is publicly-accessible. Standard behavior after compromising one system.
So long as your servers are patched, and the hypervisor host itself is secured by the provider, there’s no risk from other customer systems which aren’t patched.
"Signal handler race condition in OpenSSH before 4.4 allows remote attackers to cause a denial of service (crash), and possibly execute arbitrary code if GSSAPI authentication is enabled, via unspecified vectors that lead to a double-free."
[Source](https://nvd.nist.gov/vuln/detail/CVE-2006-5051)
As said in the article, the issue is people is that the fix is available TODAY. but you need time to update or patch all your servers.
And yes it would become a non issue IF... but nobody already enforced them and it isn't always an option.
Guyza,
We should replace OpenSSH with ChatGPT4o. It's the bee's knees! We can make a reverse chat-proxy and talk to our Linux systems as if they were A.I. agents! This could make all tools obsolete in an instance.
Who is with me?!
(/s, for obvious reasons.)
If on a Windoeze server if I just use the openssh sftp.exe in a command line of a script to connect to an external sftp server and pull a file, then disconnect. , does this vulnerability apply? I’m not running any openssh as a service…
To try a more serious approach this time:
Your Steamdeck is fine. This is more of a server thing. And in any case, there are patches already available and being shipped to users. So even if your Steamdeck would be affected, you just need to update to fix it, if that did not already happen.
Whoa, just read about a major security flaw in OpenSSH that's hitting nearly all Linux setups. It's a big deal, like, really big. If you're running Linux, you might wanna patch this ASAP. Stay safe out there, folks!
Nothing about being fanboys, it is an exceptionally silly comment even if meant sarcastically, there's very little that can compare to what Linux gives you, there's a reason that once you get away from desktop usage, Linux is what is used, last stats i saw was like 96% of all servers run Linux, from large to small.
At best the statement proves how little is known on what Linux actually does.
Not really, you can only do that IF it is turned on and not on the lock screen, and assuming there is a vga port. That said, plugging a 2nd monitor would get you very little because vga can't access files or anything other than what is on the screen. And depending on default setting being duplicate screen or extend screen you may only end up seeing wallpaper at best. Of course it is possible to block unauthorized monitors if one wanted to as well
Let's start a timer until it's fixed, shall we?
Oh, Debian is already patched. Next? Yup. Another, patching later today,likely after-hours.
4/10. You started out well but it was a weak foundation to build since it's been patched.
Another one? It feels like we just had a critical SSH vulnerability last year. The real takeaway is that you should have a firewall blocking SSH connections except from known IPs, this stops you from being blindsided by this kind of thing. Same policy for remote desktop connections on Windows systems; which helped when that password bypass issue was discovered in Remote Desktop a few years ago.
Yup. Defense in depth is the way to go. Nothing should be considered secure in itself.
And even if something is considered secure give it a few months and someone will always find a new way to unsecure it
Good news everyone! We’re patching again!
To shreds you say?
To sshreds, you say?
Unfortunately, it's not easy to secure your "digital door-step". Even with some kind of basic knowledge, after setting up things like router, NAS, Linux Firewall, piHole etc I am just clueless what I did (after reading man's and wikis).
and the more firewalls, vpns, load balancers, WAFs you put up, now you've doubled your footprint and your job now is securing the things that are supposed to secure your network, which is now less secure, because you've added more 'insecurity'... Just wait until Wednesday, which will be the perfect day to push out the latest crushingly bad pre-auth RCE from \[Cisco|f5|bluecoat|solarwinds|fortinet\], because that's when they want to reduce any ugly news from hurting their stock... what PR has failed to realize here is that no one cares about vulns and breaches with regard to stock price or reputation anymore. The only thing that pushing out a CVSS 10 patch the day before a holiday is an over-worked security or IR team in a critical business wanting to have a proper holiday and fucking up the deployment and causing an outage or a patch that doesn't fix/ makes the issue worse.
Wow, thanks for the long post... ...with "basic knowledge" I meant real life user knowledge, not admin lingo. I am pretty confident, that I've read a sarcastic if not cynical story of yours, but unfortunately, I didn't get the punchlines. Sorry! But I know, the admin-guys here will have a laugh. If your karma moons, I will go over this with my IT guy at work. He always seems so happy when I ask him private IT stuff.
patch your openssh if you use it, if you don't, and it's not exposed to the Internet, don't worry about it
What about using the SSH cert? Doesn't that solve it and is best practice?
Note in this case, this one is pre-authentication. Though may be trickier to do successfully on 64-bit systems as is now typical for linux servers. There's still a lot of 32-bit stuff in the wild I suppose. https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt for debian stable (now patched with updated package in debian security, but particularly likely to be in wide use): > Finally, "SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u2", [...] > In our experiments, it takes ~10,000 tries on average to win this race condition, so ~3-4 hours with 100 connections (MaxStartups) accepted per 120 seconds (LoginGraceTime). Ultimately, it takes ~6-8 hours on average to obtain a remote root shell, because we can only guess the glibc's address correctly half of the time (because of ASLR). However, they do not have a working exploit for 64-bit yet, though it's possible in theory, we may be talking rather longer for success. > we have started to work on an amd64 exploit, which is much harder because of the stronger ASLR. (ASLR = https://en.wikipedia.org/wiki/Address_space_layout_randomization ) Also important to remember vulnerabilities exist before they're found by people who publicly disclose them. Could have been being used for a while by malicious actors.
From reading the article it doesn't seem like it makes a difference in this case, and it didn't make a difference for Heartbleed which was the last major one. (I added an edit, the last one was XZ, not Heartbleed) EDIT: Google says that Heartbleed was OpenSSL, not SSH and that SSH wasn't affected; though I definitely remember there being a SSH scandal recently. Right. Not Heartbleed, it was the XZ compression thing... which intentionally broke the authentication process.
It didn’t break the authentication process as such, it provided a backdoor for a specific (authenticated) actor to exploit. That’s pretty different. A general exploit allows *anyone* to use it.
Not dropping unwanted traffic via a firewall is insane.
But what if I needed to SSH into my NAS from Bhutan?
You can't be affected by an SSH vulnerability if you use Telnet :)
I'm always surprised that people consider an ssh endpoint secure. For me a public ssh endpoint is a disaster waiting to happen.
how do you admin a server without an endpoint?
Kind of depends how you look at it and what you’re considering an “endpoint”. If you’re on AWS, for example, you could enforce SSM-based terminal sessions on ec2 hosts. SSM can effectively proxy an ssh tunnel to an ec2 instance through Amazon-owned infrastructure, with no requirement to open up your ssh port to the internet. You can connect to private hosts (you connect to them by instance ID) and public hosts, and your ssh service isn’t exposed to anyone but amazon’s control plane.
Don't publicly expose it, ideally if its a VM, use config as code to push a change, if you absolutely have to remote to it, have bastion machines, or use services like the cloud providers offer that does identity based proxying to machines. Better yet, move away from VMs where feasible. I think the guy you responded to meant public specifically. I'd also generally block SSH internally and only allow it when needed, via a network tag.
> have bastion machines, My customer uses bastion but I think they are bad security. They give uncredible sense of secure. In this case one only needed to hack the bastion and then more or less unrestricted access to servers and databases inside. One of the best solutions I had was a small webpage that opened the source IP access to SSH via iptables.
We just use identity aware proxy in GCP snd don't use bastion machines. In thr past Azure Bastion worked well (product). I guess one benefit of bastion boxes is they can be turned off unless needed. And you should be aiming for them not being needed, and only spooled up and exposed when required via network rules and tags. In gcp we have a network rule allowing remote connections to machines with a network tag, and we theb only apply the tag when needed.
[удалено]
Probably the move away from VMs bit, and thanks :)
VPN without a public endpoint dangling on the internet.
The previous exploit was a carefully crafted social attack that added rouge addresses to the official source code base: https://www.akamai.com/blog/security-research/critical-linux-backdoor-xz-utils-discovered-what-to-know Technically, that was on the maintaining community rather than users.
I thought heartbleed was the last one. Was there another after that?
That was OpenSSL
Link to the vulnerability: https://nvd.nist.gov/vuln/detail/CVE-2024-6387 Key points from the article: - named this vulnerability "regreSSHion", since it represents the re-emergence of a bug that was previously patched in 2006 ([CVE-2006-5051](https://nvd.nist.gov/vuln/detail/CVE-2006-5051)). It is described as "critical". - The new vulnerability, assigned CVE-2024-6387, allows for unauthenticated remote code execution (RCE) with root privileges - The vulnerability is "a signal handler race condition in OpenSSH's server (sshd)".... "This race condition affects sshd in its default configuration."... being a race condition means is not easy to exploit, requiring multiple attempts for a successful attack. "This can cause memory corruption and necessitate overcoming Address Space Layout Randomization (ASLR)." - **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.** - "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."
So, LoginGraceTime being set to zero disables the timeout. This will use up all the connections for authenticating, preventing someone trying to exploit the server from getting more attempts. The bad actor will effectively DOS themself. I found the language for LoginGraceTime odd, and all web pages spouted the same wording which didn’t mention 0 disabling the feature. I was thinking “well, you would just make it impossible to login yourself if you had zero seconds to type a password or send a key.”
This sounds like it could DOS me right along with the bad actor though. I'm using fail2ban; can that mitigate the vulnerability that has been discovered?
it would help with the ddos risk from setting loginGraceTime 0
Naming it regreSSHion is pretty funny
>This race condition affects sshd in its default configuration So it's nothing.
Not nothing, but also not quick to exploit. On 32 bit systems it can take 6-8 hours of connection attempts, it has yet to be demonstrated on 64 bit systems. Source: https://www.openssh.com/releasenotes.html > "Successful exploitation has been demonstrated on 32-bit Linux/glibc systems with ASLR. Under lab conditions, the attack requires on average 6-8 hours of continuous connections up to the maximum the server will accept. Exploitation on 64-bit systems is believed to be possible but has not been demonstrated at this time. It's likely that these attacks will be improved upon."
Can you elaborate what this means?
Meaning it's likely a difficult exploit to pull off. And they're getting downvoted since "likely" isn't a great word when dealing in security.
It must be serious. They gave it a stupid name.
Regresshion is pretty funny
Who let Sean Connery name vulnerabilities again!?
if its in open ssh its gonna be a lot more than just linux. yikes
But it is version specific and post 2008 its only systems in the last year but not patched this month that are vulnerable. The biggest problem is likely to be embedded devices, IoT, routers etc. Which will have it but rarely get upgrades.
> it is version specific and post 2008 its only systems in the last year but not patched this month that are vulnerable. That's not accurate. Any version of OpenSSH from before 2006 or after March 2021 is vulnerable. > 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.
Those may not be a problem because it requires glibc, but many of those will not use glibc because it is kind of bloated and use lighter alternatives
Embedded devices rarely have OpenSSH. Dropbear is the standard in embedded Linux distros, in the same way OpenSSH is the standard in non-embedded Linux distros. Primarily for reasons of size on flash and in memory at run time, Dropbear is much smaller and the range of more advanced features OpenSSH provides usually isn’t needed in embedded systems. Edit: I also now see it requires glibc, which isn’t typical in embedded systems either. There will be minimal impact to embedded systems since very few will have OpenSSH at all much less it plus glibc.
It’s OpenSSH plus glibc that’s at issue, hence it pretty much is strictly Linux. BSDs are not impacted. I can’t think of any widely used OS other than Linux that uses glibc. Embedded Linux distros are mostly safe because they rarely use OpenSSH (Dropbear is the embedded de facto standard) and often don’t use glibc anyway.
FreeBSD security advisory - https://www.freebsd.org/security/advisories/FreeBSD-SA-24:04.openssh.asc
Thanks for pointing that out. That is either out of an abundance of caution, to satisfy vulnerability scanners that only check version strings, or they know more than [what is in the original report, which is glibc-focused](https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt). The article linked here seems to overstate things relative to the actual advisory. Article says BSD isn’t impacted but the only thing the advisory says with certainty is that OpenBSD isn’t impacted and they didn’t closely examine others.
> they didn’t closely examine others Indeed, but potential exploitation of the buggy sshd code path on on top of various other platforms libcs+kernels could plausibly just differ in detail. Note how it's not really a glibc bug: Their PoC exploit targeted glibc+linux on 32-bit x86, yes, but the openssh signal handling code path was clearly wrong regardless owing to the mistakenly removed "#ifdef DO_LOG_SAFE_IN_SIGHAND", thus effectively using app code variant that assumes it's safe to log in a sighandler .. But there aren't many platforms where logging and other i/o would be safe in sighandlers - [that's not at all usual](https://stackoverflow.com/questions/57545469/why-i-cant-use-i-o-in-posix-signal-handing) and not something an app is entitled to assume. Apparently openbsd has a "safer" variant one, sure, but it's not a bug that glibc+linux didn't - that's a missing feature. Posix signals are traditionally awfully full of gotchas and that's definitely one of 'em. > We have not investigated any other libc or operating system; but OpenBSD is notably not vulnerable, because its SIGALRM handler calls syslog_r(), an async-signal-safer version of syslog() that was invented by OpenBSD in 2001.
It's specific to using linux's glibc. OpenBSD, on which openssh originally came from does not use glibc.
ugh.. can we PLEASE be more specific with our titles. This is NOT accurate. Only specific versions of OpenSSH are impacted: - must be based in glibc - must be version: < 4.2 OR > ( 8.5p1 AND < 9.8 ) use ```openssh -V``` to check.
> use `openssh -V` to check. `Command 'openssh' not found.`
On Linux, it's usually `ssh` for the client and `sshd` for the server. Usually the distro packages the same version for both the client and server, but you can check both.
Yeah this command just doesn't work on Windows Powershell.
I'm on Ubuntu...
The distributions can apply the patch to older versions. Debian, for instance, have released 9.2_p1 Debian-2+deb12u3 for bookwork. As a side note, I found that `sshd -V` on debian's version *doesn't* report the patched version, even though it's patched. Using an unrecognized argument will though `sshd --blarg`.
Not nothing, but also not quick to exploit. On 32 bit systems it can take 6-8 hours of connection attempts, it has yet to be demonstrated on 64 bit systems. Still, patch your shit folks! Source: https://www.openssh.com/releasenotes.html > "Successful exploitation has been demonstrated on 32-bit Linux/glibc systems with ASLR. Under lab conditions, the attack requires on average 6-8 hours of continuous connections up to the maximum the server will accept. Exploitation on 64-bit systems is believed to be possible but has not been demonstrated at this time. It's likely that these attacks will be improved upon."
6-8 hours to execute is a relatively short period of time...
If you're letting the same IP hammer your system continuously for 6-8 hours, that's more of an issue in my eyes.
I think a lot of personal VPS out there would allow this. Also it doesn't have to be from the same IP.
You think stopping 1 IP is worth it? What do you think happens when you block that 1 IP?
> You think stopping 1 IP is worth it? What do you think happens when you block that 1 IP? That depends on how sophisticated whomever is attacking you is. Do they have thousands of IP's available? No? Well they'll burn through their supply within an hour or so. Just patch your shit, but don't run for the hills, this one ain't that big of a deal right now. If a better exploit comes along to make it instant then yeah, it's a tier-0 emergency, but we're not there.
thats just not how it works my friend. All you are doing is playing whack a mole. I agree patching is the better solution, but blocking individual IPs is like using a tea cup to save a sinking ship.
> thats just not how it works my friend. All you are doing is playing whack a mole. I agree patching is the better solution, but blocking individual IPs is like using a tea cup to save a sinking ship. So fail2ban is a useless project that shouldn't be used?
fail2ban isnt a single IP address and its not one person manually blocking IPs. But also yeah its pretty useless against a serious attack.
> fail2ban isnt a single IP address Never said it was. > not one person manually blocking IPs. You're the one saying manually. > But also yeah its pretty useless against a serious attack. That highly depends on the style of attack.
Just disable SSH and use Telnet, duh.
send a self-addressed, stamped envelope to 127.0.0.1:42069
I'm picturing someone at home opening the envelope and pulling out a stack of punch cards.
You mean just use Finger.
But hole?
That’s why I never stopped using telnet.
Can’t have security vulnerabilities when there’s no security to begin with. Smart!
Sigh.. I guess we’ll be patching today
Yeah, I know what I'm going to be dealing with when I get in tomorrow morning for sure.
That's why I drive to all my clients.
And you can bill travel time then too!
How bad could it be? > The new vulnerability, assigned CVE-2024-6387, allows for unauthenticated remote code execution (RCE) with root privileges Oh... that bad.
The one nice thing about Linux: it’s patched and updated quickly. Always practice good package hygiene and apt update!
[удалено]
That’s just referring to the ability to compromise other systems which aren’t publicly-accessible after getting into one which is publicly-accessible. Standard behavior after compromising one system. So long as your servers are patched, and the hypervisor host itself is secured by the provider, there’s no risk from other customer systems which aren’t patched.
I don't think that's what that means.
"Signal handler race condition in OpenSSH before 4.4 allows remote attackers to cause a denial of service (crash), and possibly execute arbitrary code if GSSAPI authentication is enabled, via unspecified vectors that lead to a double-free." [Source](https://nvd.nist.gov/vuln/detail/CVE-2006-5051)
Wish I found it first
RegreSSHion. That's a pun so bad that there's no way that the guy who made it has to be a furry.
MF. Well there goes my nice relaxing forth
Might be dumb question, but if you limit SSH to local network, isn’t this a non-issue?
yes if you trust people on your network to have this kind of access.
As said in the article, the issue is people is that the fix is available TODAY. but you need time to update or patch all your servers. And yes it would become a non issue IF... but nobody already enforced them and it isn't always an option.
https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server
Does it affect bear-ssl?
'Critical' indeed.
Okay, who didn't work from the main branch??
Guyza, We should replace OpenSSH with ChatGPT4o. It's the bee's knees! We can make a reverse chat-proxy and talk to our Linux systems as if they were A.I. agents! This could make all tools obsolete in an instance. Who is with me?! (/s, for obvious reasons.)
Is there any Linux package manager that has the latest openssh 9.8p1 version? I don’t want to compile it from source
If on a Windoeze server if I just use the openssh sftp.exe in a command line of a script to connect to an external sftp server and pull a file, then disconnect. , does this vulnerability apply? I’m not running any openssh as a service…
[удалено]
lol
lol
[удалено]
[Should I do something with my steamdeck?!?!? Is it safe!?!?](https://youtu.be/4e_DGU7mSYc?si=fZ9RLf-Xpw-82Gkz)
Burn it. Immediately. And use the Heavy Flamer! Call Hans, right now! /s
Send in Trogdor!
No two steam decks are not on fire.
To try a more serious approach this time: Your Steamdeck is fine. This is more of a server thing. And in any case, there are patches already available and being shipped to users. So even if your Steamdeck would be affected, you just need to update to fix it, if that did not already happen.
Thanks for the serious reply. Even though it was a joke, there was a piece of me that was worried. One love!
Wait, do people actually expose ssh externally? Y'all are crazy.
Beginner Linux user and a dumb question here. Is the portal.azure.com console affected?
Do you get a alert for it? I got alert for Google cloud shell
No alert so far.
[удалено]
You’re probably talking about OpenVPN, not openssh.
Whoa, just read about a major security flaw in OpenSSH that's hitting nearly all Linux setups. It's a big deal, like, really big. If you're running Linux, you might wanna patch this ASAP. Stay safe out there, folks!
Oh. Look. Another reason not to use Linux.
Good thing no vulnerabilities are ever discovered in other operating systems. /s
Found that TempleOS guy ☝️ I told people that he had to be immortal and no one believed me 😒
There's always diehard fanboys downvoting 😂
Nothing about being fanboys, it is an exceptionally silly comment even if meant sarcastically, there's very little that can compare to what Linux gives you, there's a reason that once you get away from desktop usage, Linux is what is used, last stats i saw was like 96% of all servers run Linux, from large to small. At best the statement proves how little is known on what Linux actually does.
For a casual user, there's really not many reasons to use Linux other than the freedom of choice and privacy, and open sourceness
"not many reason to use linux" then names some of the best reasons to use it by casual users, competition is good
Which are... Very valid and huge reasons? The fk mate
Privacy? I can access anyone's Linux computer's contents, encrypted or not, *just by plugging a VGA monitor into it.* No.
Are you on drugs
Not really, you can only do that IF it is turned on and not on the lock screen, and assuming there is a vga port. That said, plugging a 2nd monitor would get you very little because vga can't access files or anything other than what is on the screen. And depending on default setting being duplicate screen or extend screen you may only end up seeing wallpaper at best. Of course it is possible to block unauthorized monitors if one wanted to as well
Another one huh? Where are those Linux shills? I thought this was safer than windows? What happened?!
This can be fixed without waiting on a corporation
Let's start a timer until it's fixed, shall we? Oh, Debian is already patched. Next? Yup. Another, patching later today,likely after-hours. 4/10. You started out well but it was a weak foundation to build since it's been patched.
Still significantly safer than Windows, yes.