SSH, CVE-2024-6387

nerozero

nerozero

Hi there,

I have red several papers about this vulnerability, but still not clear, does it effects freebsd ssh daemon ( which for me on FreeBSD 13.3, sshd version: OpenSSH_9.6p1, OpenSSL 1.1.1w-freebsd 11 Sep 2023 ) or not?
pkg audit -F doesn't seems to show this vulnerability.

Temporary fix according to the paper is to set in /etc/ssh/sshd_config
Code: 
LoginGraceTime 0

More about CVE:
https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt
https://vulcan.io/blog/cve-2024-6387-how-to-fix-regresshion-vulnerability/
 
nxjoseph Thanks but, its not corrected in p4, sshd is still vulnerable to this threat:
IV. 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.
Click to expand...
 
richardtoohey2 I guess I'm not correctly understood the "workaround" part. Does that means that vulnerability is still present in case of setting LoginGraceTime to 0, but it is corrected by p4 update (which disables the content of the logging function sshsigdie() )?
 
If you apply the patch, you don't need the workaround.

The workaround is an emergency measure if you don't have time to patch. For example if you have a critical system and you need to wait until an agreed downtime period before you apply patches, you can use the workaround.

Some places will have procedures/policies etc. etc. and they won't just patch away.

That's what the wording usually means; but I'm definitely not an expert.

So either patch OR change the setting (the workaround). You can probably do both to be on the safe side.

The patch won't change the ssh configuration file, just the binaries.
 
nerozero said:
does it effects freebsd ssh daemon [...] or not?
Click to expand...

Yes and no. The "regreSSHion" exploit contains two stages.

Yes, the OpenSSH daemon in FreeBSD (and all other OS that use the affected upstream codebase) also suffers from that race condition:
We discovered a vulnerability (a signal handler race condition) in
OpenSSH's server (sshd): if a client does not authenticate within
LoginGraceTime seconds (120 by default, 600 in old OpenSSH versions),
then sshd's SIGALRM handler is called asynchronously, but this signal
handler calls various functions that are not async-signal-safe (for
example, syslog()). This race condition affects sshd in its default
configuration.
Click to expand...

And no, the RCE that makes this an actual threat does not apply to FreeBSD (or other BSDs and illumos), but only to systems using gnu libc:
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.
Click to expand...

(quotes taken from the original advisory from qualys: https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt)
 
The version didn't change, you can verify that it was changed by doing:
strings /usr/sbin/sshd | grep FreeBSD.
On my systems this output:
FreeBSD
FreeBSD
FreeBSD
FreeBSD-20240701
FreeBSD clang version 18.1.5 (https://github.com/llvm/llvm-project.git llvmorg-18.1.5-0-g617a15a9eac9)
Linker: LLD 18.1.5 (FreeBSD llvmorg-18.1.5-0-g617a15a9eac9-1400006)
Click to expand...
While sshd -V gives
OpenSSH_9.7p1, OpenSSL 3.0.13 30 Jan 2024
Click to expand...
As you can see, the timestamp is in the binary file which give the hint that the patch is applied.
 
What the fix does is to drop problematic part of code with #if 0 and #endif, and bump SSH_VERSION_FREEBSD.
For example, link to commit on main branch. This is MFC'ed into all supported branches.
Unfortunately, this bump does not appear on neither freebsd-version nor sshd -V. Would be just trigger rebuilds for codes depending on OpenSSH including itself.
 
T-Aoki said:
… this bump does not appear on … freebsd-version …
Click to expand...

FreeBSD-SA-24:04.openssh, yes?

Where freebsd-update was used, the patch level should be evident with option -u, for example:

Code: 
root@mowa219-gjp4-vm-freebsd-14-zfs:~ # freebsd-version -kru ; uname -aKU
14.1-RELEASE
14.1-RELEASE
14.1-RELEASE-p2
FreeBSD mowa219-gjp4-vm-freebsd-14-zfs 14.1-RELEASE FreeBSD 14.1-RELEASE releng/14.1-n267679-10e31f0946d8 GENERIC amd64 1401000 1401000
root@mowa219-gjp4-vm-freebsd-14-zfs:~ # freebsd-update fetch ; date
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching metadata signature for 14.1-RELEASE from update2.freebsd.org... done.
Fetching metadata index... done.
Fetching 2 metadata patches.. done.
Applying metadata patches... done.
Fetching 2 metadata files... done.
Inspecting system... done.
Preparing to download files... done.

No updates needed to update system to 14.1-RELEASE-p2.
Wed Jul  3 03:25:13 BST 2024
root@mowa219-gjp4-vm-freebsd-14-zfs:~ #

Where pkgbase was used, no discrepancy between kernel and userland patch levels (both 2):

Code: 
root@mowa219-gjp4-vm-freebsd-14-zfs:~ # pkg update --repository FreeBSD-base && pkg update --repository FreeBSD-ports
Updating FreeBSD-base repository catalogue...
FreeBSD-base repository is up to date.
All repositories are up to date.
Updating FreeBSD-ports repository catalogue...
FreeBSD-ports repository is up to date.
All repositories are up to date.
root@mowa219-gjp4-vm-freebsd-14-zfs:~ # uname -mvKU ; freebsd-version -kru
FreeBSD 14.1-RELEASE-p2 releng/14.1-n267684-1eba659e2f68 GENERIC amd64 1401000 1401000
14.1-RELEASE-p2
14.1-RELEASE-p2
14.1-RELEASE-p2
root@mowa219-gjp4-vm-freebsd-14-zfs:~ #
 
For official update builds from releng/* branch, yes.
For main (aka -Current) and stable/* branches, -p* would not appear. Need to see whether the commit hash is earlier than the fix or not.
 
T-Aoki said:
What the fix does is to drop problematic part of code with #if 0 and #endif, and bump SSH_VERSION_FREEBSD.
For example, link to commit on main branch. This is MFC'ed into all supported branches.
Unfortunately, this bump does not appear on neither freebsd-version nor sshd -V. Would be just trigger rebuilds for codes depending on OpenSSH including itself.
Click to expand...
The patch does this because upstream OpenSSH (OpenBSD) removed that function entirely. The #if 0 in effect neuters the function without removing all the calls to it (like the upstream patch does). This mitigates the problem without the additional churn of touching the rest of OpenSSH. Effective until a new OpenSSH is imported, which should be soon as I saw an import into the vendor branch earlier this week.
 
You must log in or register to reply here.
Back
Top