How can we upgrade current SSH version to 9.8 or higher without Homebrew on macOS Ventura?

The only issues here are with the reporting tool, and with the response to the report.

macOS sshd is not effected, per what Qualys themselves have posted.

More generally: Please don’t immediately apply the remediation suggested by add-on anti-malware. Not without giving the detection and the remediation some consideration. Consideration whether the add-on anti-malware is correct, and consider whether the detection even matters, or if things are mis-detecting or are just busted. Busted? More than a little add-on anti-malware has (erroneously) suggested doing bad things to macOS.

Want details about this case? Ask Qualys support.

Given the following information from Qualys does not apply to your configuration, you will want to report the errant Qualys detection bug, or the errant suggestion or confusing Qualys documentation or whatever kicked over this quest, to Qualys support:

The Qualys Threat Research Unit (TRU) has discovered a Remote Unauthenticated Code Execution (RCE) vulnerability in OpenSSH’s server (sshd) in glibc-based Linux systems. CVE assigned to this vulnerability is CVE-2024-6387.

1: This isn’t Linux, and 2: macOS uses libc and not glibc.

How to back out the sshd changes might unfortunately be a project. If there are backups from prior to those changes, I might consider restoring those. Otherwise, homebrew can hopefully remove what it added.

If you want to learn about this Linux sshd bug involving glibc, here is the Qualys report:

https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server

CVE-2024-6387 is a vulnerability that only affects OpenSSH running on Linux systems that use glibc.

As such, macOS devices are not impacted as macOS doesn't use the Linux kernel, and uses Apple's own libSystem instead of glibc.

In my experience, when a vulnerability like this is disclosed, the scope of the vulnerability can broaden, or subsequent vulnerabilities are found, since more focus is put on the affected components by security researchers and threat actors.

Then new CVE's will be created for the newly discovered vulnerabilities, and if any of them are related to Apple, then Apple will release a security update.

But as it stands the broken code is in the GNU glibc library, and Apple does not use glibc.

And installing your own OpenSSH is actually MORE likely to bring along a glibc library with the flaw, then just continuing to use Apple's compiled OpenSSH.

Since it may well arise in the context of this thread, there's a second sshd vulnerability now being reported:

CVE-2024-6409: OpenSSH: Possible remote code execution in privsep child due to a race condition in signal handling

This second CVE in addition to CVE-2024-6387 discussed in the thread above. Which does not apply to macOS. The CVE text for this second sshd vulnerability does not contain the information I'd expect to find in a CVE, but—from other information posted elsewhere—it appears that this second CVE is (also) not relevant to macOS.

• https://www.openwall.com/lists/oss-security/2024/07/08/2
• https://www.openwall.com/lists/oss-security/2024/07/09/2

From that second link: It's disappointing that this CVE states that this is a vulnerability in OpenSSH sshd, and fails to make clear that this only affects Redhat versions and users of their downstream patch.

ii_mj wrote:

I do see it but our SIEM which is Qulays is showing severe vulnerability to our MACs. That is why I raised a question here as this should only impact Linux systems but why is it showing for MACs?

I would inquire with Qualys as their information appears to be erroneous.

jmillet89 wrote:

The real question is whether the vulnerability can be exploited on non-glibc, linux based systems.

Here are the technical details of the flaw: https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt\

The flaw is a regression in glibc, around (re-)permitting a signal handler race condition within glibc, and specifically that free() is not async safe, and that the glibc malloc() can get tangled with unlink().

As libc is not glibc, it may well have other flaws, but is unlikely to have this flaw, and this regression. But is it possible that libc has this same flaw? Conceivably, sure. Start by checking whether the libc free() and malloc() have the cited issues. Source code to libc is available, of course.

Or if you're particularly concerned about ssh in general, switch to a VPN for your connections. Now can a VPN server have security issues? Sure. Some have, too. Is your particular selected VPN server vulnerable? Donno. Zyxel had CVE-2023-33009 and CVE-2023-33010, for instance. Cisco ASA security has been problematic, too.

Reactive security is always going to be racing exploits and chasing fixes (see above), and will be chasing detections (see CrowdStrike). If you want to try to improve upon the reactive approach and particularly on the problems inherent with trying to maintain a security perimeter, have a look at implementing BeyondCorp, among other possibilities.

And yes, this whole area of computer security has been awash in hype. As an example of some widely-resported issues, I’m unaware of any documented uses of speculative-level attacks, for instance. Are those attacks possible? Sure. Are espionage entities using exploits based on speculation flaws, or on other low-level or speculative flaws? Quite possibly, yes. But if that's happening, it’s not getting much reporting. Which could mean the flaws aren’t being widely exploited, or that nobody has the instrumentation to detect those or differentiate those crashes from bit flips or other random crashes, or nobody has noticed.

As for this ssh flaw involving glibc, I’m not all that concerned. Not outside of the specified Linux servers.

To expand on BobHarris's comment, this from the same page you linked to:

Affected OpenSSH versions 

• OpenSSH versions earlier than 4.4p1 are vulnerable to this signal handler race condition unless they are patched for CVE-2006-5051 and CVE-2008-4109. 
• Versions from 4.4p1 up to, but not including, 8.5p1 are not vulnerable due to a transformative patch for CVE-2006-5051, which made a previously unsafe function secure. 
• The vulnerability resurfaces in versions from 8.5p1 up to, but not including, 9.8p1 due to the accidental removal of a critical component in a function.

So, if you did install OpenSSH in macOS, it would depend on what version you installed as to whether or not you've opened a vulnerability. As read (and it's not well written), any version between 4.4p1 and before 8.5p1, and 9.8p1 (and later?) are safe.

That Qualys blogpost does not say macOS is not affected. In regard to macOS, the article says, "its exploitability on these platforms remains uncertain."

The NVD and CVE sites do not specify glibc as a dependency for the vulnerability at the time of this post:

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

https://nvd.nist.gov/vuln/detail/CVE-2024-6387

The proof-of-concept was only achieved on a glibc-based Linux systems, but that does not mean other sshd installations are not vulnerable.

jmillet89 wrote:

source?

Apple. Had there been a vulnerability, Apple would have patched it.

These things go viral about once a month now. It's always the same. A bunch of IT people with no clue about Apple platforms think they have the need, and the ability, to patch it for some vulnerability they heard about on the internet or that their Leader in Risk-Based Vulnerability Management Platforms told them about.

Don't believe me? Just hop on a Delta Airlines flight to Cupertino and ask Apple yourself. Oh, wait... you can't do that, can you? I guarantee you that Delta had patched this sshd vulnerability on their systems right away. Same for all the other companies trying not rebuild their systems after trusting their security to these people.

etresoft wrote:

jmillet89 wrote:

source?

Apple. Had there been a vulnerability, Apple would have patched it.

These things go viral about once a month now. It's always the same. A bunch of IT people with no clue about Apple platforms think they have the need, and the ability, to patch it for some vulnerability they heard about on the internet or that their Leader in Risk-Based Vulnerability Management Platforms told them about.

Don't believe me? Just hop on a Delta Airlines flight to Cupertino and ask Apple yourself. Oh, wait... you can't do that, can you? I guarantee you that Delta had patched this sshd vulnerability on their systems right away. Same for all the other companies trying not rebuild their systems after trusting their security to these people.

The claimed that a company would have patched the vulnerability if it existed, and therefore, the vulnerability does not exist since that company has not patched it (especially within the same month it was disclosed) is very flimsy.

The real question is whether the vulnerability can be exploited on non-glibc, linux based systems. To my knowledge, that has not been confirmed one way or the other. I have read the posts on this thread stating the issue is in glibc itself, but besides Qualys framing the vulnerability as "on glibc linux-based systems" without great detail, I have not seen it confirmed substantially anywhere else.

In my experience, when a vulnerability like this is disclosed, the scope of the vulnerability can broaden, or subsequent vulnerabilities are found, since more focus is put on the affected components by security researchers and threat actors.

Ignore it. Doesn't apply to Macs.

glib is not used by Apple. The vulnerability is in glib code.

ii_mj wrote:

We use Qualys and it is reporting as severe vulnerability for all our MAC estate.

https://www.qualys.com/regresshion-cve-2024-6387/

Here is the link to Qualys detection. Our MACs are on 9.6 and they need to be on 9.8 as per the vulnerability fix.

<sigh>

Same story. Every time. Does literally no one ever read the details of these hacks? Whether they are instant, or take 8 hours of sustained hacking? Whether they are in the wild, or theoretical? You can literally just read the text on this page. None of that compares to the Gospel of the Vulnerability Scanner. It Hath Been Written in the CVE! All Hail The CVE!

ii_mj wrote:

I do see it but our SIEM which is Qulays is showing severe vulnerability to our MACs. That is why I raised a question here as this should only impact Linux systems but why is it showing for MACs?

Why are you asking us? We didn't write your Qulays.