CVE Detection

[cschuber]

I don't know if there's a better way to do this but running ssh-audit against a RHEL server's sshd seems to result in false CVE reporting. For example, my FreeBSD systems, which use OpenSSH 9.6p1, will correctly report all CVEs being fixed because FreeBSD usually imports OpenSSH (though may backport patches when an import is not possible at the time). But RHEL servers, including RHEL 9.2, report CVEs that RH has documented as being fixed. ssh-audit version vulnerability database (versionvulnerabilitydb.py) performs a simple version check, which BTW commercial products such as Tennable also do. False reporting of CVEs makes no sense because Red Hat backports patches to their "ancient" openssh, updating the Red Hat build number in the RPM version number.

I think this gives a false sense of problem when there may not be. I suspect other Linux distros may do the same.

I don't know if it is worth expanding the vulnerability database to include vendor build numbers, not report on CVEs for vendor supplied OpenSSH, or simply provide an option not to report on the CVE. This is a similar problem I see with Tennable's Nessus product. Simple version number checks tell auditors and others that there is a problem when there may not be, and it casts doubt on the validity of the output. I understand the difference but others (auditors) may not.

An option may be to document this.

Just looking for you comment about this one way or another.

[jtesta]

The CVE code was written by the original author. I did make some additions to its database over time, but I haven't kept up with it... mainly for the same reasons you've mentioned: because they're solely based on version checks, which often lead to inaccurate results due to distros back-porting fixes.

I think its time to consider removing the CVE functionality. Not only does it give many false positives, but users have rarely complained that it hasn't been updated in quite some time with the latest vulns. I'm thinking very few people, if any, are consuming this info.

Let's use this post to vote from now until August 1, 2024. Anyone who wants to keep the version check-based CVE info, add a thumbs-down ( 👎 ) to this post.

[skull-squadron]

Version-based CVE "checking" is a bad idea and leads to mission creep.

Guessing based on version banners will produce both false alarms (false positives) and, worse, potentially a false sense of security (false negatives) in some instances which would be catastrophic.

This method of vulnerability auditing is extremely fragile because top-tier LTS Linux distros backport patches (albeit with some delay) to numerically "vulnerable" versions but don't consistently update their server banners to something that can be distinguished.

Instead, the gold standard of vuln auditing is using real, precise, accurate, and {,semi-}benign PoCs for each CVE to probe a service to determine with high confidence if they are actually patched. And it's far easier to roll out vulnerability auditing, management, and remediation on systems with local access, in which case "whitebox" testing is much easier. If one needs remote CVE management, the usual vendors like Tenable, Rapid7, CrowdStrike and similar vendor(s) exist and already have solutions. Unfortunately, independently cobbling together high-confidence CVE detection isn't something that would be cheap, quick, or easy.

If instead choosing to continue down this road, perhaps start with 1 CVE and create automated testing that can reliably prove detected on all major systems with both known vulnerable and known patched release packages. The fixed setup costs of this feature will be both a lot of work and require nontrivial rigor to ensure correctness.

Either way, PSA: please secure your systems with regular updates and do the work yourself to audit vendor's package source to verify remediation patches have been applied.

[FlyingPhish]

I agree it's probably best to comment out the CVE stuff until a more robust function is created.