sshd CVE-2024-6387 vulnerability
-
attackers would still need ssh and port 22 open on the wan connection enabled.
Note
"Because the malloc of this Ubuntu's glibc is already hardened against
the old unlink() technique, we decided to transform our arbitrary free()
into the Malloc Maleficarum's House of Mind (fastbin version): we free()
our own NON_MAIN_ARENA chunk, point our fake arena to sshd's .got.plt
(this Ubuntu's sshd has ASLR but not PIE), and overwrite _exit()'s entry
with the address of our shellcode in the heap (this Ubuntu's heap is
still executable by default). For more information on the Malloc
Maleficarum: ..."pfSense utilizes FreeBSD or OpenBSD and not Ubuntu
SSH-2.0-OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3 (Debian 3.0r6, from 2005)
SSH-2.0-OpenSSH_4.2p1 Debian-7ubuntu3 (Ubuntu 6.06.1, from 2006)
SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u2 (Debian 12.5.0, from 2024)
None of the underline Operating Systems are FreeBSD based that are shown in this reports details. Do you know if this was also attempted in FreeBSD?
@stephenw10 Have you looked at this let? I mean how can this interrupt freeBSD if the system has PHP limits and all the other memory hardening already built into FreeBSD and OpenBSD? This looks to be specific to Ubuntu and Debian
-
@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.
