Jump to content

Are there any mitigations for CVE-2024-6387?


Go to solution Solved by Rysz,

Recommended Posts

Obviously you should minimize the amount of devices having access to SSH on the machine. But that's best-practice anyway.

 

According to the Ubuntu documentation, you could configure LoginGraceTime: https://ubuntu.com/security/CVE-2024-6387

For doing this in Unraid:

  1. Check if /boot/config/ssh/sshd_config already exists. If not: cp /etc/ssh/sshd_config /boot/config/ssh/sshd_config
  2. Configure "LoginGraceTime 0", I also recommend adding a comment.
  3. Restart SSH (Settings --> Management access --> Set "Use SSH" to "off", apply, turn on again and apply again). Or restart the machine.
  • Upvote 1
Link to comment
  • Solution
Posted (edited)
11 hours ago, TomWis97 said:

Obviously you should minimize the amount of devices having access to SSH on the machine. But that's best-practice anyway.

 

According to the Ubuntu documentation, you could configure LoginGraceTime: https://ubuntu.com/security/CVE-2024-6387

For doing this in Unraid:

  1. Check if /boot/config/ssh/sshd_config already exists. If not: cp /etc/ssh/sshd_config /boot/config/ssh/sshd_config
  2. Configure "LoginGraceTime 0", I also recommend adding a comment.
  3. Restart SSH (Settings --> Management access --> Set "Use SSH" to "off", apply, turn on again and apply again). Or restart the machine.

 

I'd seriously advise against this as it closes one very unlikely problem to just open up another much more likely problem:

This makes sshd vulnerable to a denial of service (the exhaustion of all MaxStartups
connections), but it makes it safe from this vulnerability.

A denial of service attack is much easier to perform than the discovered exploit and much more likely to randomly happen to any range of IPs.

 

The SSH vulnerability has only been proven on 32-bit systems and under lab conditions with extensive efforts (several hours invested) so far. While it is assumed to be possible to exploit 64-bit systems as well, it seems to take considerable effort and at that point you really have to ask yourself if you are that much of a target for someone to invest such efforts to break into your Unraid system with a zero-day exploit. There's probably tons of companies out there vulnerable to this exploit right now and you think they're going to go for your Unraid server instead, to steal... what?

 

Unraid is designed for ease of use and not maximum operational security, so you shouldn't be exposing any services on your Unraid server directly to the internet. Forget SSH, reverse proxies... this should be non-negotiable - period. Users, on this subforum in particular, seem to be under the false impression that there's a point where they've taken enough steps to make Unraid safe to be exposed to the internet, this is a dangerous assumption made under a very false sense of security. A system running everything as root and not receiving in-place, zero-day security updates will never be 100% safe. Unraid is a file-server and a local network appliance aimed at providing you convenience at an acceptable degree of security (for use in your LAN - not WAN). Use it for what it can do.

 

Use a VPN to access your Unraid services from remote (if you must) and 99.99% you will not have to care about such things ever.

Put services you must directly expose inside VMs on operating systems that are designed for it, don't invest your efforts in the wrong place.

This is my personal opinion and not that of Lime Technology or any of the official Unraid staff members and/or creators.

 

Edited by Rysz
  • Upvote 7
Link to comment
Posted (edited)

Litteraly just woke up to this...
From what i have found, there are 2 options one can take in the mean time.

edit the sshd conf and replace it to add the login grace time per the mitigation in ubuntu:


*sshd plugin helps here.

 

As explained above:

Check if /boot/config/ssh/sshd_config already exists. If not: cp /etc/ssh/sshd_config /boot/config/ssh/sshd_config

 

*The running file for sshd while its on is /etc/ssh/sshd_config Unraid will replace at reboot the conf if you have a file at /boot/config/ssh/sshd_config

Since Unraid is a type of mutable OS that exist in ram the /etc/ssh/sshd_config is erased at reboot


In sshd config found under #authentication: 

image.png.f4c7bb9123a360f489f8f12f86cad365.png

Configure "LoginGraceTime 0"


I also use the SSH conf tool to help add other ssh users. As i use it for sftp file transfers.
image.png.8b9e51412c545ae033a035198e9b05b4.png
Reboot/Restart SSH (Settings --> Management access --> Set "Use SSH" to "off", apply, turn on again and apply again). Or restart the machine.

 


Or add fail 2 ban before sshd to help minimize the connections.

image.png.822dd48bbf0028af6e032820f2abb553.png
also the deny host plugin may help here...

image.png.ba9049dc83484766f7f0950aae939d4c.png


openssh said the exploit requires continuous connection for 6-8 hours. If you limit the # of connection (which is what the setting login grace time) to 5 by default IIRC per fail to ban or lower. 2-3 ... This will mitigate the exploitation.

Edited by bmartino1
Link to comment

I know that the major distros (RHEL [and clones], Amazon Linux, Debian, and Ubuntu) have already released patches on Monday for this CVE. Any plans on porting one of those to Unraid since the required modifications are out there already?

Link to comment
9 hours ago, ThatDude said:

It's been >3 days and you have to assume a percentage of the user base have SSH exposed either deliberately or accidentally.

Why would you assume that?  One would need to actively open their server's address and port to expose themself to the Internet.

Link to comment

I set up a machine on its own VLAN blocked from everything else, with port 22 wide open to the wild. Username root and password password. The filesystem has over 100,000 folders, 6-10 deep, every folder has between 1 and 5 GOATSE photos. And that's all.

Link to comment
On 7/4/2024 at 1:05 AM, ConnerVT said:

Why would you assume that?  One would need to actively open their server's address and port to expose themself to the Internet.

Are you being serious? Have you met 'people' ?

 

I think a better question might be where is the formal policy on patching CVEs? unRAID is a mature paid for product relied upon by X thousands of users around the world.

I'm not sure if unRAID enables SSH on a default install (it used to), but if it does what steps are taken to secure the SSH service? Such as disabling root logins by default, key based auth ONLY, enabling the 'deny hosts' plugin etc etc.

 

Offering general advice to not expose unRAID's SSH to the internet is not a formal security policy, and does nothing to protect the unRAID box from lateral movements of hackers that have gained access to the LAN.

  • Upvote 1
Link to comment
Posted (edited)
1 hour ago, ThatDude said:

Are you being serious? Have you met 'people' ?

 

I think a better question might be where is the formal policy on patching CVEs? unRAID is a mature paid for product relied upon by X thousands of users around the world.

I'm not sure if unRAID enables SSH on a default install (it used to), but if it does what steps are taken to secure the SSH service? Such as disabling root logins by default, key based auth ONLY, enabling the 'deny hosts' plugin etc etc.

 

Offering general advice to not expose unRAID's SSH to the internet is not a formal security policy, and does nothing to protect the unRAID box from lateral movements of hackers that have gained access to the LAN.

 

It was always my understanding and use-case that Unraid is - first and foremost - a convenient file storage solution for use in a LAN. I bought it exactly for that what it provides, convenience for in-home file storage use at an acceptable and mostly basic degree of security for inside my local network. If you're worried about 'lateral movements of hackers that have gained access to the LAN' and if your risk assessment has really concluded that as a likely scenario to happen to you, you either seriously need to reconsider your network security so that doesn't happen (enterprise firewalls, air-gapping, compartmentalization etc.) or look into other more enterprise-oriented solutions.

 

Unraid has always patched vulnerabilities as part of their regular update cycles, this is not something that was just recently changed or unknown to the majority of people. It seems to me you're comparing apples to oranges here. If you need a bulletproof vest because you are at risk of being shot at, invest in one and don't ask your t-shirt manufacturer to take your very personal risk scenario into consideration for everyone else wearing t-shirts.

 

Considering this exploit was only proven on 32-bit systems and takes hours of serious effort to actually take advantage of, some of you are blowing this way out of proportion - in my humble and unofficial personal opinion.

 

Edited by Rysz
  • Like 2
Link to comment
41 minutes ago, ThatDude said:

Are you being serious? Have you met 'people' ?

 

Offering general advice to not expose unRAID's SSH to the internet is not a formal security policy, and does nothing to protect the unRAID box from lateral movements of hackers that have gained access to the LAN.

 

Unraid's primary use case is not to open it up to a WAN and the greater Internet.  It is an appliance meant for one's local LAN network.  It is designed and built for that purpose, and expectations that it is infallible to all off use implementations are not valid.

 

Are some people stupid?  Certainly.  But you can't fix stupid.  All you can try to do is protect people from themself, but that comes with a cost.  you could lock down the system so tight that much of Unraid's usability is lost, hire someone who sole responsibility is to test and develop fixes for exploits (and pass that cost to the users) and pass patch after patch for us to update (then chase reports of "update broke my server..." we constantly see in the forum, many unrelated to Unraid software).  But even making patches available, many people never update (and now the new business model will have even less people doing so).

 

Unraid is not a plug-and-play NAS appliance.  It is a highly configurable server platform.  With the former, there is an expectation the vendor has a responsibility to fully protect you.  Being stupid does not forgive you of your responsibility to protect yourself.

  • Like 1
Link to comment
Posted (edited)
1 hour ago, ThatDude said:

I'm not sure if unRAID enables SSH on a default install

It doesn't.

Being exposed to the vulnerability requires someone to deliberately turn it on and port forward it or otherwise expose it to the internet, against all advice, and IMO bears the responsibility for it.

Edited by Kilrah
  • Like 1
Link to comment
Posted (edited)
2 hours ago, JorgeB said:

It doesn't, but 6.12.11 with an updated OpenSSH should be released soon.

 

Thanks @JorgeB Could you comment on what the formal security policy is for unRAID?

 

It looks like a version point update is released every 4-12 weeks, is that the baseline for security patches too?

 

I'm genuinely surprised by the responses in this thread, I think we should fully expect level 8 CVEs to be patched in a timely manner, if end users don't install those patches then sure, that's on them. Even if the devs don't want to patch anything until the next release cycle that's fine, just be upfront about it. Apologies in advance if this has already been formally answered by the devs, I didn't see it anywhere.

Edited by ThatDude
typo
  • Upvote 1
Link to comment
19 hours ago, ThatDude said:

Could you comment on what the formal security policy is for unRAID?

Can't comment on that, you'd need to ask someone from LT, the only info I have is that 6.12.11 should be released soon, hopefully this upcoming week, with openSSH updated. 

  • Like 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...