sshd CVE-2024-6387 vulnerability

marcg

Are recent versions of pfSense vulnerable to CVE-2024-6387 (details)?

pfSense+ 24.03's sshd appears to be a vulnerable version. I don't know whether the other conditions, e.g., glibc(), are met.

[24.03-RELEASE][admin@pfSense.home.arpa]/root: sshd -V
OpenSSH_9.6p1, OpenSSL 3.0.13 24 Oct 2023

I'm curious even though ssh from the WAN is not permitted to this machine. Thx.

JonathanLee

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

marcg

@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.

JonathanLee

@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."

stephenw10

Theoretically. See: https://www.freebsd.org/security/advisories/FreeBSD-SA-24:04.openssh.asc
Workaround patch incoming.

marcg

@stephenw10, thanks.

JonathanLee

@stephenw10

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?

stephenw10

Yes, the patch will set that.

slu

And the patch is already there, good work Netgate!

stephenw10

See: https://forum.netgate.com/topic/189010/netgate-security-advisory-cve-2024-6387

tedquade

@stephenw10 Will a fix for this be incorporated in the next 24.09-Development release?

Ted

stephenw10

Yes 24.08 will have an updated openssh version.