OpenSSH CVE-2024-6387

[Patrick M. Hausen]

Hi folks!

Are we in for a quick hotfix?

https://www.freebsd.org/security/advisories/FreeBSD-SA-24:04.openssh.asc

Kind regards,
Patrick

[AdSchellevis]

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

[Monviech (Cedrik)]

Doesn't this mean FreeBSD isn't vulnerable?

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.

[Patrick M. Hausen]

See my link in the initial post. That's the advisory by the FreeBSD security team clearly stating that it is.

[Monviech (Cedrik)]

Oops only read second link.

[newsense]

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.

[JeGr]

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:

Code Select Expand

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

[Greg_E]

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?

[opnsense-user123]

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.

[Patrick M. Hausen]

All supported branches plus 13.2 (which is technically EOL but only for two day, now) received an SSH update that fixes the issue.

[mimugmail]

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. :)

[bestboy]

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

[Hydraulix989]

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?

[AdSchellevis]

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

[squarepantsii]

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.