CVE-2024-6387 Possible RCE in openssh

[cmidkiff87]

A signal handler race condition was found in OpenSSH's server (sshd), where a client does not authenticate within LoginGraceTime seconds (120 by default, 600 in old OpenSSH versions), then sshd's SIGALRM handler is called asynchronously. However, this signal handler calls various functions that are not async-signal-safe, for example, syslog().

Might want to add a check for this

https://www.cve.org/CVERecord?id=CVE-2024-6387

[jtesta]

Thanks for this reminder, though there is a proposal to remove all of the CVE information from ssh-audit due the inherent inaccuracy in header version checks (see https://github.com/jtesta/ssh-audit/issues/240#issuecomment-1913749629).

[cmidkiff87]

It might be a good idea to add an actual check for this specific one, considering the potential for unauthenticated root level RCE

I'm not sure how you would do that without a simple version number comparison, but the potential for abuse seems pertinent

Relevant links

• https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server
• https://cwe.mitre.org/data/definitions/364.html

[jtesta]

On a technical level, the logic needed to give an accurate answer to the user doesn't currently exist in the code base.

When the Terrapin attack was published (CVE-2023-48795), OpenSSH fixed it in v9.6. Ubuntu 20.04 back-ported the fix to OpenSSH 8.2p1 and Ubuntu 22.04 back-ported it to OpenSSH v8.9p1--both without changing the version numbers. So simply checking for versions less than 9.6 would cause over 99% false positives.

Ubuntu includes additional package information in the protocol header (SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.7), so in theory, the package version might give enough information to make an accurate assessment. However, no code currently exists to parse this package info. Issue #89 was opened three and a half years ago which suggested writing this code; until 10 minutes ago, that issue had the "help wanted" tag on it, but no one in the community was interested.

Even if that code were written, how does every other Linux distro handle patches? Does Amazon Linux include patch information in the protocol header? Or Rocky Linux? Or Alpine? Or Arch?

[fropert]

To me relying on banner version check is invalid strategy for this bug. Rocky Linux/Yocto just return the legacy openssh version. There is no custom patch naming convention that is standardized across all linux distributions. In embedded system, banner checking won't work as developers apply the patch at code level. In my opinion, there should be a ssh-audit check only if the vuln can be checked at runtime with dynamic testing and by taking in consideration that there may be a rate-limiter too. Otherwise, it should stay into the source code scan realm.

[jtesta]

As per the community vote results (see https://github.com/jtesta/ssh-audit/issues/240#issuecomment-2377414379), all version-based CVE information has been removed in https://github.com/jtesta/ssh-audit/commit/93b30b42584cef103652b426ab62c0e8b32e2667.

This issue is now moot and is closed. Nevertheless, your participation in this project is still appreciated! Thanks for contributing!!