SSH, CVE-2024-6387

[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

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]

It must have been corrected in 13.3-RELEASE-p4.

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

 

[nerozero]

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.

 

[richardtoohey2]

its not corrected in p4, sshd is still vulnerable to this threat

That's news to most people - what do you base that statement on? Not saying you are incorrect, but that's not what my understanding of the situation is.

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

Corrected:...2024-07-01 08:27:10 UTC (releng/13.3, 13.3-RELEASE-p4)

 

[nerozero]

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() )?

 

[richardtoohey2]

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]

Ah ok then. thanks.

 

[richardtoohey2]

Definitely keep an eye on the security news and someone will come along and whack me with a cluebat if I'm wrong. But I think I'm correct.

 

[richardtoohey2]

See, for example:

Over 14M servers may be vulnerable to OpenSSH's regreSSHion RCE flaw. Here's what you need to do

OpenSSH, the bedrock of secure Linux network access, has a nasty security flaw.

www.zdnet.com

“If you can't install a patch for some reason, consider protecting yourself against the regreSSHion vulnerability by setting LoginGraceTime to 0 in the sshd configuration file”

 

[sko]

does it effects freebsd ssh daemon [...] or not?

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.

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.

(quotes taken from the original advisory from qualys: https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt)

 

[PMc]

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:

Let's say, there is no public knowledge of a working RCE for FreeBSD.

 

[gopiio]

I have updated system. It is running the correct patch.

freebsd-version
14.0-RELEASE-p8

When I check the sshd version, I can't see any changes. Is that expected?

sshd -V
OpenSSH_9.5p1, OpenSSL 3.0.12 24 Oct 2023

As per this commit, https://cgit.freebsd.org/src/commit/?h=releng/14.0&id=70eb00f17b310f599b60939c1afa326c7b2c390c I was expecting the timestamp to be 20240701. Is that the expected behavior?

 

[monwarez]

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)

While sshd -V gives

OpenSSH_9.7p1, OpenSSL 3.0.13 30 Jan 2024

As you can see, the timestamp is in the binary file which give the hint that the patch is applied.

 

[T-Aoki]

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.