sshd CVE-2024-6387 vulnerability
-
@JonathanLee , no idea as to the other OSs that were tested, although OpenBSD seems to be immune. Hoping that the pfSense devs will chime in.
Guessing that the vulnerability exists from the LAN side as well. Blocking ssh from the WAN is a good start, but not complete protection in that case.
-
@marcg I see it I was searching for FreeBSD
"This vulnerability is exploitable remotely on glibc-based Linux systems,
where syslog() itself calls async-signal-unsafe functions (for example,
malloc() and free()): an unauthenticated remote code execution as root,
because it affects sshd's privileged code, which is not sandboxed and
runs with full privileges. 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." -
Theoretically. See: https://www.freebsd.org/security/advisories/FreeBSD-SA-24:04.openssh.asc
Workaround patch incoming. -
@stephenw10, thanks.
-
Workaround
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.Is this the recommendation for older versions of pfSense currently?
-
Yes, the patch will set that.
-
And the patch is already there, good work Netgate!
-
-
@stephenw10 Will a fix for this be incorporated in the next 24.09-Development release?
Ted
-
Yes 24.08 will have an updated openssh version.
-
J JeGr referenced this topic on
