Hi folks!
Are we in for a quick hotfix?
https://www.freebsd.org/security/advisories/FreeBSD-SA-24:04.openssh.asc
Kind regards,
Patrick
Hi Patrick,
This will be addressed next week from our end.
Looking briefly at the report https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt?ref=upstract.com, at a first glance exploitation on amd64 seems to be rather difficult (and time consuming) by the way.
Best regards,
Ad
Doesn't this mean FreeBSD isn't vulnerable?
Quote
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.
See my link in the initial post. That's the advisory by the FreeBSD security team clearly stating that it is.
Oops only read second link.
The only confirmation is that OpenBSD went a different route with OpenSSH in 2001 and they're not affected.
There's no confirmation yet on FreeBSD, however the security team there decided they'll patch first and ask questions later - as Colin explained it on Twitter shortly after the vulnerability bacame public.
Unless something changes and somehow the bug becomes trivial to exploit on FreeBSD there's no real urgency to have this patched in OPNsense this week - - other than pleasing an otherwise hard to please and non-affilated Youtuber.
Anything Linux however is a Patch Now if exposed to the internet.
From what I could read in various CVE Trackers, not all Linux needs "patch now". There's much alarmism thrown around. Reading the bug report I stumbled upon "only tested on 32bit systems, 64bit is still ongoing". Huh...
But for FreeBSD the workaround is mentioned to:
If sshd(8) cannot be updated, this signal handler race condition can be
mitigated by setting LoginGraceTime to 0 in /etc/ssh/sshd_config and
restarting sshd(8). This makes sshd(8) vulnerable to a denial of service
(the exhaustion of all MaxStartups connections), but makes it safe from the
remote code execution presented in this advisory.
The DOS part shouldn't take too much, as I guess the lockout daemon would handle them before it gets to exhaustion anyways. So for anyone wanting a quick fix AND has SSH on WAN needed and not being able to disable it: changing that in sshd_config would do as workaround patch, wouldn't it?
Cheers :)
\jens
I foresee another video coming out... Why I don't... Yes it seems the other firewall pushed out a fix and it seems to set to zero saving you the work of doing it yourself.
Setting to zero or blocking from the WAN is probably a good idea for a while.
Will Suricata detect this and block it? Seems like it would detect the pattern of constantly trying to force SSH and block the attempts. If not today, will it tomorrow?
Just a point of reference, my FreeBSD email server received an update (14.1-RELEASE-p2). This did not set "LoginGraceTime 0" so it must have actually patched ssh.
All supported branches plus 13.2 (which is technically EOL but only for two day, now) received an SSH update that fixes the issue.
Quote from: Patrick M. Hausen on July 02, 2024, 10:17:00 PM
All supported branches plus 13.2 (which is technically EOL but only for two day, now) received an SSH update that fixes the issue.
Even if 13.2 wouldn't get it, Franco would patch it anyway .. we already saw similar things in 11.1 etc. :)
iXSystems has released a new TrueNAS version 13.0-U6.2 [1] with the FreeBSD fix back ported to 13.0 [2]
[1] https://www.truenas.com/docs/core/13.0/gettingstarted/corereleasenotes/#130-u62
[2] https://ixsystems.atlassian.net/jira/software/c/projects/NAS/issues/NAS-129828?jql=project%20%3D%20%22NAS%22%20ORDER%20BY%20created%20DESC
Hey OPNsense, are we going to take this seriously and get an update out??
All of my other remote-facing networking systems have already had patches at this point...
What's the delay?
As stated on the top of this thread, next week. (https://forum.opnsense.org/index.php?topic=41342.msg202804#msg202804)
And yes, we are taking it serious, FreeBSD's patch is a precaution, which is obviously fine, but FreeBSD doesn't use glibc and OPNsense is also not available on 32bit systems.
Best regards,
Ad
Quote from: Patrick M. Hausen on July 02, 2024, 10:17:00 PM
All supported branches plus 13.2 (which is technically EOL but only for two day, now) received an SSH update that fixes the issue.
I am still finding my way around the software stack. What does "all supported branches plus 13.2" mean?
If I do a # ssl -V, I get OpenSSH_9.7p1. Do this mean that this is not vulnerable?Just re-read the Qualys notice, and this version is vulnerable. My question above still stands, thanks.
FreeBSD published updated versions for all supported releases and also for release 13.2 which is already EOL, but they fixed it, anyway.
Supported releases at the moment are: 13.3, 14.0, 14.1.
One thing to note here for clarity is that we do not have OpenSSH in the base system so the advisories do not even apply from that FreeBSD version EoL or not point of view:
https://github.com/opnsense/tools/commit/477358606e
The update will be done via openssh-portable package through the FreeBSD ports tree. Expect the update tomorrow.
Cheers,
Franco
Any updates yet? Did this update make it into OpnSense? pfSense handled it right away...
Quote from: Hydraulix989 on August 03, 2024, 08:38:02 PM
Any updates yet? Did this update make it into OpnSense? pfSense handled it right away...
Yeah, pfSense handled exactly nothing in the non-paid version except for the upstream documented workaround. Next release will come in a couple of years, maybe.
It's been fixed almost a month ago, not sure what update are you expecting. https://forum.opnsense.org/index.php?topic=41505.0
Just to follow up on the previous: Yes, the correct way is to update to OpenSSH 9.8p1, which we did in 24.1.10 on July 11. It's a bit of a shame that allegedly serious issues are patched in a major release, but it is what it is.
Cheers,
Franco