Netgate Security Advisory: CVE-2024-6387
-
@JonathanLee Gotcha yeah the latest is 2.2.11_13
-
@planedrop That is part of the 24 plus software I can't run it because the package I utilize the most is not fully set up yet on it.
-
If one disables ssh as admin access to the pfSense box, there is no exposure to this, yes?
Can one enable ssh but on a specific interface instead of all interfaces, say "enable ssh for admin access only on internal/LAN interfaces but not WAN"? If so, that would limit exposure to only systems on LAN, yes?
-
@mer One can block access with firewall rules.
Iād recommend never allowing direct access to pfSense from WAN.
-
@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.
-
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...
-
@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.
-
@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.
Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
Upvote š helpful posts! -
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.
-
@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...
-
@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.
-
@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.
-
@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
-
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?
-
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.
-
@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.
-
@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.
-
@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.
-
M mwatch unpinned this topic on
