CVE-2023-48795 false positives

[rebeccaui]

Fleet version: 4.58

Web browser and operating system: macOS 14 and 15

---

💥  Actual behavior

CVE-2023-48795 lists libssh2 1.11.1 as vulnerable while NVD does not.
It also shows kitty as vulnerable on macOS but NVD says Windows only.
Paramiko 2.11.0 shows as vulnerable but NVD does not.

🧑‍💻  Steps to reproduce

1. TODO
2. TODO

🕯️ More info (optional)

N/A

[JoStableford]

Linked to Unthread ticket:

False Positives in Vulnerability Listings #3439)

[sharon-fdm]

Hey team! Please add your planning poker estimate with Zenhub @iansltx @lucasmrod @mostlikelee

[iansltx]

Need to confirm which OS we're looking at here. That screenshot looks like Linux, which would be pulling from a distro-specific OVAL (or ALAS for Amazon Linux) rather than our NVD feed. If I had to guess, that's what's going on with libssh2 in particular, though I'm going to test further.

For kitty, there was a broader CPE but it got deprecated. I'll need to figure out why the deprecated CPE is showing up in the vuln feed rather than the replacement CPEs. Will prioritize hunting this down since we should be able to fix that with a vuln feed build rather than a full release.

For paramiko, I just checked the changelog and 3.4.0 was the version that got the CVE fix; 2.11.0 didn't (it wasn't backported either), so everything < 3.4.0 is indeed vulnerable and we're marking that correctly.

[iansltx]

Did some digging on kitty and there's no such thing as macOS kitty. NVD superseded the CPE on their website from a generic one to a Windows-specific one, but the tighter CPE doesn't get delivered via their API as part of the CVE, and Vulncheck doesn't have the more specific CPE exposed either. So unless I'm missing something significant there's no issue here either, as "kitty for Windows is vulnerable" matches "kitty for all OSes is vulnerable."

[iansltx]

For libssh2, something seems to be up; adding the following to the CVE test gets me CVEs that don't include a resolved-in version:

		"cpe:2.3:a:libssh2:libssh2:*:*:*:*:*:*:*:*": {
			includedCVEs: []cve{
				{ID: "CVE-2023-48795", resolvedInVersion: "1.11.1"},
			},
			continuesToUpdate: true,
		},

[MScottBlake]

Did some digging on kitty and there's no such thing as macOS kitty. NVD superseded the CPE on their website from a generic one to a Windows-specific one, but the tighter CPE doesn't get delivered via their API as part of the CVE, and Vulncheck doesn't have the more specific CPE exposed either. So unless I'm missing something significant there's no issue here either, as "kitty for Windows is vulnerable" matches "kitty for all OSes is vulnerable."

Perhaps you can explain this then?

[iansltx]

Turns out, multiple developers independently called something kitty; the one above is a completely different application unaffiliated with the PuTTY fork that was mentioned in the CVE.

This also clarifies that the packages listed above are all on homebrew, so that's useful information as well. Will continue working through this; thanks!

[iansltx]

So, for libssh2, I ensured I had libssh2 1.11.1 on my machine (via brew) and confirmed that I don't see it listed as vulnerable. @MScottBlake are the hosts you're seeing marked as vulnerable also macOS/homebrew?

As for kitty, coincidentally #22944 (and the corresponding PR #24593) will fix this issue, as the app bundle identifier for kitty (which we get from the apps table) gives us enough information to build a specific enough CPE to not match CVE-2023-48795, and we're dropping reporting on Homebrew packages that also show up as apps. Which means that this:

will turn into this:

So we're down to troubleshooting why you're seeing libssh2 1.11.1 false-positives, as I can't repro them on macOS + homebrew, across multiple Fleet servers running 4.61.0.