Netgate Security Advisory: CVE-2024-6387

planedrop

@SteveITS answer is correct, you can use firewalls to restrict SSH access.

Best practice is to not allow it on the WAN ever, and personally I don't allow it at all in most of my environments, I just completely disable it.

Least privilege, minimum required functionality, is usually the way to go.

mvikman

Workaround for SSH CVE-2024-6387 (After applying, restart the SSH Daemon or reboot. https://www.freebsd.org/security/advisories/FreeBSD-SA-24:04.openssh.asc)

diff --git a/src/etc/sshd b/src/etc/sshd
index 4b4ee3f72a..efc2680eac 100755
--- a/src/etc/sshd
+++ b/src/etc/sshd
@@ -106,7 +106,7 @@ if (config_get_path('system/ssh/sshdkeyonly') == "both") {
        $sshconf .= "PubkeyAuthentication yes\n";
 }
 $sshconf .= "UseDNS no\n";
-$sshconf .= "LoginGraceTime 30s\n";
+$sshconf .= "LoginGraceTime 0s\n";
 /* Hide FreeBSD version */
 $sshconf .= "VersionAddendum none\n";
 if (config_path_enabled('system/ssh', 'sshdagentforwarding')) {

Don't know if compatible with other version than 24.03, use at your on risk...

mer

@SteveITS @planedrop
Thanks. I agree with both, my answer/question was more of a Socratic method "If we read and understand what the CVE actually says, are there trivial things we can do to mitigate or avoid it?"

I've been reading CVEs for a long time. Most people have knee jerk reaction to them, immediately want to be able to point a finger/blame someone else. The reality of a lot of CVEs is they depend on specific sets of circumstances. This one on SSH: if you do not enable ssh access on WAN, you can say "eh, minor, catch it in the future". If you enable on WAN you say "OMG gotta do something, either patch or workaround or something".

I want people to read CVEs and actually THINK.

But thanks for your replies.

SteveITS

@mer said in Netgate Security Advisory: CVE-2024-6387:

want people to read CVEs and actually THINK

Oh my, you know this is the Internet right?

I believe I've read fail2ban or a similar method to block failed login attempts is a mitigation. Also that the original Linux bug was only proven on 32 bit OSs.

There was some hollering on 3CX and other forums to "fix it!" as well, but realistically no one should expose SSH without a good reason, so I doubt those folks were reading the details either.

planedrop

@SteveITS

It was only proven on 32 bit, but I think the theory is it could still happen on 64 bit, just no one has managed to do it yet lol.

But yeah, regardless, SSH needs to not be exposed where possible.

mer

@SteveITS said in Netgate Security Advisory: CVE-2024-6387:

Oh my, you know this is the Internet right?

Well, it's my fantasy world, so...

JonathanLee

@planedrop A lot of users access this remotely over a VPN after just SSH in to the command line for the firewall for remote administration at times.

planedrop

@JonathanLee Sure, and doing it over a VPN isn't a bad idea, I just personally think avoiding enabling SSH when at all possible is a good thing.

JonathanLee

@planedrop yes again if your managing many boxes and doing cyber security testing with VMs it's not really an option to disable it 100 percent

LesserBloops

Could System Patches possibly be preinstalled as a placeholder in the future, so that when looking for updates to apply, it'll appear in the average user's package list?

I had no idea System_Patches existed until happening upon this thread, and if it's going to be used to deliver security updates, that seems important enough to install by default?

Gertjan

@LesserBloops

It had a special "Here a new pfSense package that might interest you" introduction last February on the main announcement channel, the pfSense Blogs, and the many (loads of) references here on the forum.
As such, it was also very visible here on the dashboard, the RSS feed which show the last xx blogs posts.
It's part of the pfSense package list, and the description is (should be) pretty self explaining :

Patches are are most often "quality of live" additions that can be applied by small (pfSense GUI) script changes.

SteveITS

@LesserBloops Also of note Netgate pins patches package update messages in https://forum.netgate.com/category/16/pfsense-packages.

If it's a security update fixed for an older version also they put it in the release notes: https://docs.netgate.com/pfsense/en/latest/releases/2-7-1.html#security

I've seen your suggestion posted before so Netgate's aware of it. However because of how the package functions it won't be that obvious anyway...the admin must update the package first in order to see the new list of patches. Otherwise only the original set is listed.

dennypage

@LesserBloops said in Netgate Security Advisory: CVE-2024-6387:

Could System Patches possibly be preinstalled as a placeholder in the future, so that when looking for updates to apply, it'll appear in the average user's package list?

This seems a reasonable suggestion.

Gertjan

@LesserBloops said in Netgate Security Advisory: CVE-2024-6387:

I had no idea System_Patches existed until happening upon this thread

Yeah .... well, scrap what's I've said above.
I'll rephrase, and express my real opinion :
It must be a package, so when an update exists, it will get flagged on the dashboard as 'update == patches' exist. That's the great thing about the pfSense package system.
I was wondering : why isn't this build into pfSense directly ? But that would mean that there will be another thing to check, pfSense packages updates and patches updates. Another dashboard widget ?
So : upon pfSense installation : advise the user to pick this package ?
Or, don't signal the admin, and install the package without admin consent ?
Humm, maybe not ...

Right now, any package is installed with admin consent, as you have to install them 'ones'.

Parches proposed by this package are only mostly 'quality of live' amelioration. But ones in a while they are a must have, as it solves a real issue. Then the question doesn't exist anymore : people will find the forum for support, will find that there is a solution ... a patch, and so on ...

Real issues, like urgent software updates like (example) curl, unbound nginx etc etc (tyhese are not pfSense packages, but FreeBSD packages ! - or FreeBSD updates ported to their pfSense equivalent by Netgate ) are already getting updated using the command line ( SSH or console !! ) option 13.

@LesserBloops : I've got one for you : Auto update check, checks for updates to base system + packages and sends email alerts
"Install" that one also. You maybe not knowing it, but you need it
Btw : you will need to install the Cron pfSense package.

This script file tells me, as I receive a mail, if anything has an upgrade waiting. Even pfSense itself.