Netgate Security Advisory: CVE-2024-6387
-
Is this patch available for users running older versions of pfSense example 23.05?
-
@JonathanLee If you install and update the System Patches package, then you can check under System > Patches to see if it's available.
On a 23.09 system I have in my lab it is available, I don't have any 23.05 to test though.
-
@planedrop No it is not there I have patches version 2.2.9_1 does not list it.
-
@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.
