[FP]: use a negative rule for cpe:2.3:a:sms:sms:*:*:*:*:*:*:*:* suppression matching for Maven artifacts

[FyiurAmron]

Package URl

pkg:maven/

CPE

cpe:2.3:a:sms:sms::::::::

CVE

CVE-2005-2311

ODC Integration

{"label"=>"Gradle Plugin"}

ODC Version

11.1.1

Description

The CVE is due to https://bugs.gentoo.org/97187 ; it's 20 years old 2.1 base score advisory, and no maven package exists that physically can have it, thus an umbrella suppression for pkg:maven can be added.

Example rule:

    <suppress base="true">
        <notes><![CDATA[
        FPs from #2995 (sms)
        ]]></notes>
        <packageUrl regex="true">^pkg:maven\/.*$</packageUrl>
        <cpe>cpe:/a:sms:sms</cpe>
    </suppress>

[github-actions]

Error parsing package url: pkg:maven/.

Error: Error: Invalid purl: "name" is a required component

Please correct the package URL - consider copying the package url from the HTML report.

[github-actions]

Failed to automatically evaluate the false positive. See: https://github.com/jeremylong/DependencyCheck/actions/runs/12322937891

[github-actions]

Error parsing package url: pkg:maven/.

Error: Error: Invalid purl: "name" is a required component

Please correct the package URL - consider copying the package url from the HTML report.

[github-actions]

Failed to automatically evaluate the false positive. See: https://github.com/jeremylong/DependencyCheck/actions/runs/12322969493

[FyiurAmron]

I'm more than willing to do the PR here etc. if that's of any use.

[aikebah]

@FyiurAmron The sms:sms appears to be an issue only for proprietary libraries. Those are up to the end-users and prorietary vendors to fix with their own proprietary suppression files. Hosted-suppressions file deals with suppression of improper CPEs for publicly available/consumable libraries.

[FyiurAmron]

@aikebah not really, bear with me.

1. the current resolution of CPE is improper, and this issue falls under what you say: no Maven artifact exists that has this vulnerability, because it wasn't related to Maven ecosystem or libraries at all. Checking the actual vuln report from my initial post makes that apparent; it affected only little-known-and-used app-mobilephone/sms package in Gentoo ecosystem (not existent as verbatim Gentoo package anymore I think - traces of the old package can still be found in https://cgit.gentoo.org/repo/gentoo.git/plain/app-mobilephone/sms/?id=b494a03e939708fe28d16e9d2a2bd000e7b5244f e.g. , and I also think it's now renamed to https://packages.gentoo.org/packages/app-mobilephone/smstools - but honestly that's beyond me, as I'm not a Gentoo expert and this is ancient history anyway), with a score of 2.1, 20 years ago. That's it. Matching any Maven repo by CPE is thus simply invalid and a FP.

2. the argument about public libraries doesn't strictly make sense in general; anyone can make a Maven lib publicly available, and if the rule makes no sense (see 1.), easily prove the point you raised about "no FP public Maven libraries" completely factually invalid.

3. the sms word is common enough by itself in package names. This should make it obvious that adding an upstream suppression rule after considering the actual vuln report is reasonable by itself, even if no package is falsely marked by the scanner yet (which is however not the case here - see below)

4. you're wrong in the exact sense as well. There are currently long-existing publicly available libraries that are affected, just not a single person reported them yet before me I think. Some of them by well-known and reputable vendors, some by random people and companies publishing their artifacts. Doing a quick query on MVN or Central by youself (e.g. https://search.maven.org/search?q=a:sms etc.) will probably provide you with some offenders. I can provide some from the top of my head from a PoC project (I can provide a GH link if you want, but you can just paste those impl refs to any Java project of your choosing and do a depcheck):

sms-0.0.2.aar (pkg:maven/com.adkhambek.pack/[email protected], cpe:2.3:a:sms:sms:0.0.2:*:*:*:*:*:*:*) : CVE-2005-2311
sms-0.3.0.jar (pkg:maven/com.wgtwo.api.v0.grpc/[email protected], cpe:2.3:a:grpc:grpc:0.3.0:*:*:*:*:*:*:*, cpe:2.3:a:sms:sms:0.3.0:*:*:*:*:*:*:*) : CVE-2017-7860, CVE-2017-7861, CVE-2017-8359, CVE-2017-9431, CVE-2020-7768, CVE-2023-33953, CVE-2023-44487, CVE-2023-32732, CVE-2005-2311
sms-1.0.0-beta10.jar (pkg:maven/com.github.xujiaji.mk/[email protected], cpe:2.3:a:sms:sms:1.0.0.eta10:*:*:*:*:*:*:*) : CVE-2005-2311
sms-1.3.3.jar (pkg:maven/com.jdcloud.sdk/[email protected], cpe:2.3:a:sms:sms:1.3.3:*:*:*:*:*:*:*) : CVE-2005-2311
sms-1.4.2.jar (pkg:maven/com.wgtwo.api.v1.grpc/[email protected], cpe:2.3:a:grpc:grpc:1.4.2:*:*:*:*:*:*:*, cpe:2.3:a:sms:sms:1.4.2:*:*:*:*:*:*:*) : CVE-2020-7768, CVE-2023-33953, CVE-2023-44487, CVE-2023-32732, CVE-2005-2311
sms-1.8.3.jar (pkg:maven/io.basc.start/[email protected], cpe:2.3:a:sms:sms:1.8.3:*:*:*:*:*:*:*) : CVE-2005-2311
sms-jvm-1.3.95.jar (pkg:maven/aws.sdk.kotlin/[email protected], cpe:2.3:a:sms:sms:1.3.95:*:*:*:*:*:*:*) : CVE-2005-2311
sms-metadata-1.3.95.jar (pkg:maven/aws.sdk.kotlin/[email protected], pkg:maven/aws.sdk.kotlin/[email protected], pkg:maven/aws.sdk.kotlin/[email protected], pkg:maven/aws.sdk.kotlin/[email protected], pkg:maven/aws.sdk.kotlin/[email protected], pkg:maven/aws.sdk.kotlin/[email protected], pkg:maven/aws.sdk.kotlin/[email protected], pkg:maven/aws.sdk.kotlin/[email protected], pkg:maven/aws.sdk.kotlin/[email protected], pkg:maven/aws.sdk.kotlin/[email protected], pkg:maven/aws.sdk.kotlin/[email protected], pkg:maven/aws.sdk.kotlin/[email protected], pkg:maven/aws.sdk.kotlin/[email protected], pkg:maven/aws.sdk.kotlin/[email protected], pkg:maven/aws.sdk.kotlin/[email protected], pkg:maven/aws.sdk.kotlin/[email protected], pkg:maven/aws.sdk.kotlin/[email protected], pkg:maven/aws.sdk.kotlin/[email protected], pkg:maven/aws.sdk.kotlin/[email protected], pkg:maven/aws.sdk.kotlin/[email protected], pkg:maven/aws.sdk.kotlin/[email protected], cpe:2.3:a:sms:sms:1.3.95:*:*:*:*:*:*:*) : CVE-2005-2311

Consider the default CPE matching rule: ~anything /*sms* that's before 1.9.2 will be triggered here I think (I can't remember the exact depcheck package-from-CPE matching rule, but it seems awfully similar to that I think).

Is this enough or do I need to find more examples? If so, how many do you need to feel convinced here? For the reference, I'm not trying to prove you wrong for the sake of proving anything, I just want this to be sorted out finally. Need more proof, I can get you more proof. Need code, I can write the code. Need PR, I'll do the PR. I'm doing this as a part of my paid day job, and I'm paid by the hour :)

[aikebah]

@FyiurAmron those samples are enough...

The reason for me responding 'appears to be an issue only for proprietary libs' is because we've not received any FP reports apart from the earlier FP report #2995 that was talking about company-internal libraries hitting it. Those cases fall under the "that's due to how dependencycheck works; for internal libraries you'll have to mitigate the FPs resulting from it with your own suppression filter" clause.

Your response has given enough examples to warrant also adding your suggested sms fix to the list as there are multiple public libraries. Your initial report gave no such examples, leaving only the earlier reported private libraries as suspects.

[aikebah]

Miss-tagged the ticket reference, but a manual suppression has been pushed as f204335

[FyiurAmron]

@aikebah sure, my point here being mainly that any CPE with a common English word or tech name (be it the actual "sms" or "grpc" in this case, but it can obviously be just "test", "mail", "web", you name it) suffers from the very same problem. That's the point 3 in the reply/rant above. I am aware of the architectural limitations for depcheck due to how CPEs are created (i.e. the mapping to packages is done via string comparison and not precise co-ords), but I'd say that if a CPE with such "common" co-ords is reported as existing, it warrants at least a cursory investigation before a report is being rejected, on the above grounds (i.e. extremely high change of common real-life FPs existing, even if not reported explicitly). Obviously, even for relatively precise CPEs one can have the completely opposite case (e.g. some obscure private package that triggers a FP due to using a name of vulnerable tech as artifact name), but I'd say that it's the CPE form that should be the hint here - if it would be cpe:2.3:a:common:common, I'd assume it creates hundreds of real-life FPs already, even if no-one posted any.

That aside, many thanks for your help here, both me and the vuln metrics of my projects will really appreciate the effort :)

[aikebah]

There will no doubt be more of such occasions, which is the unfortunate side-effect of having to use CPE and the many single common english words used for both vendor and product in the CPEs that the NIST NVD has used over time.

For stronger bindings yielding fewer FPs one would have to resort to paid vulnerability scanners that can spend time and money building and maintaining their own proprietary mapping database from known library identifiers to vulnerabilities (or CPE coordinates).

Given the known limitations ODC has served me surprisingly well, though your mileage may vary, as its accuracy is highly depending on the libraries that you actually encounter and the level of overlap of their evidences with vendor- and product strings in the entire set of application CPEs found in the NVD.

In my day-job the rate of FPs due to improper CPEs is relatively low. Most of my encountered FP issues are on the 'large framework with multiple libs from which we use a non-vulnerable subset' and 'vendor-supported security patched library of an older open-source major/minor' (e.g. the -redhat-<nn> patch suffix versions)

At least these suppressions are now published in the hostedSuppressions, so your vuln metrics rate should improve on the next scan.