list of unrelated versions in the remediation

[TimBrown1611]

What happened:
Hello!
I've scanned an image using grype 0.84.0, and received the below CVE.
The problem is, that my package is version 17.0.2, and in the fixed versions some of the versions doesn't really to be related to the actual remediation.
I have 2 questions regarding this issue:

1. since it is an image, why we are using NVD as a source, which most of the times is less reliable?
2. can we sort the versions in a different way, which can indicate what is the actual version we can use to fix the CVE? (for example, compare each value in the list until he is higher that the actual version of the package)

let me know if you need any additional information :)

      "vulnerability": {
        "id": "CVE-2024-21147",
        "dataSource": "https://nvd.nist.gov/vuln/detail/CVE-2024-21147",
        "namespace": "nvd:cpe",
        "severity": "High",
        "urls": [
          "https://security.netapp.com/advisory/ntap-20240719-0008/",
          "https://www.oracle.com/security-alerts/cpujul2024.html"
        ],
        "description": "Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 7.4 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N).",
        "cvss": [
          {
            "source": "[email protected]",
            "type": "Primary",
            "version": "3.1",
            "vector": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
            "metrics": {
              "baseScore": 7.4,
              "exploitabilityScore": 2.2,
              "impactScore": 5.2
            },
            "vendorMetadata": {}
          }
        ],
        "fix": {
          "versions": [
            "1.8.0_421",
            "11.0.24",
            "17.0.12",
            "21.0.4",
            "22.0.2",
            "8.0.421"
          ],
          "state": "fixed"
        },
        "advisories": []
      },
      "relatedVulnerabilities": [],
      "matchDetails": [
        {
          "type": "cpe-match",
          "matcher": "stock-matcher",
          "searchedBy": {
            "namespace": "nvd:cpe",
            "cpes": [
              "cpe:2.3:a:oracle:java_se:17.0.2:*:*:*:*:*:*:*"
            ],
            "package": {
              "name": "jdk",
              "version": "17.0.2"
            }
          },
          "found": {
            "vulnerabilityID": "CVE-2024-21147",
            "versionConstraint": "< 1.8.0_421 || >= 1.9-ea, < 8.0.421 || >= 9-ea, < 11.0.24 || >= 12-ea, < 17.0.12 || >= 18-ea, < 21.0.4 || >= 22-ea, < 22.0.2 (jvm)",
            "cpes": [
              "cpe:2.3:a:oracle:java_se:*:*:*:*:*:*:*:*"
            ]
          }
        },
        {
          "type": "cpe-match",
          "matcher": "stock-matcher",
          "searchedBy": {
            "namespace": "nvd:cpe",
            "cpes": [
              "cpe:2.3:a:oracle:jre:17.0.2:*:*:*:*:*:*:*"
            ],
            "package": {
              "name": "jdk",
              "version": "17.0.2"
            }
          },
          "found": {
            "vulnerabilityID": "CVE-2024-21147",
            "versionConstraint": "< 1.8.0_421 || >= 1.9-ea, < 8.0.421 || >= 9-ea, < 11.0.24 || >= 12-ea, < 17.0.12 || >= 18-ea, < 21.0.4 || >= 22-ea, < 22.0.2 (jvm)",
            "cpes": [
              "cpe:2.3:a:oracle:jre:*:*:*:*:*:*:*:*"
            ]
          }
        },
        {
          "type": "cpe-match",
          "matcher": "stock-matcher",
          "searchedBy": {
            "namespace": "nvd:cpe",
            "cpes": [
              "cpe:2.3:a:oracle:jdk:17.0.2:*:*:*:*:*:*:*"
            ],
            "package": {
              "name": "jdk",
              "version": "17.0.2"
            }
          },
          "found": {
            "vulnerabilityID": "CVE-2024-21147",
            "versionConstraint": "< 1.8.0_421 || >= 1.9-ea, < 8.0.421 || >= 9-ea, < 11.0.24 || >= 12-ea, < 17.0.12 || >= 18-ea, < 21.0.4 || >= 22-ea, < 22.0.2 (jvm)",
            "cpes": [
              "cpe:2.3:a:oracle:jdk:*:*:*:*:*:*:*:*"
            ]
          }
        }
      ],
      "artifact": {
        "id": "9cbdf257ea42a863",
        "name": "jdk",
        "version": "17.0.2",
        "type": "binary",
        "locations": [
          {
            "path": "/usr/java/openjdk-17/release",
            "layerID": "sha256:dc9fa3d8b576eada8a4f97ca296d0db470ea7342d544e7e2f3c42715d20c2798"
          }
        ],
        "language": "",
        "licenses": [],
        "cpes": [
          "cpe:2.3:a:oracle:java_se:17.0.2:*:*:*:*:*:*:*",
          "cpe:2.3:a:oracle:jre:17.0.2:*:*:*:*:*:*:*",
          "cpe:2.3:a:oracle:jdk:17.0.2:*:*:*:*:*:*:*"
        ],
        "purl": "pkg:generic/oracle/[email protected]",
        "upstreams": [],
        "metadataType": "JavaVMInstallationMetadata",
        "metadata": {
          "release": {
            "javaVersion": "17.0.2"
          }
        }
      }
    },

What you expected to happen:
provide only related versions
How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

Environment:

• Output of grype version: 0.84.0
• OS (e.g: cat /etc/os-release or similar): mac

[westonsteimel]

This appears to be working as I would expect. This is the new JVM cataloguer in syft, and there is currently no better source than NVD CPE based matches for that. This is a record I have manually enriched in our cve-data-enrichment repo. It is showing you every possible known fixed version for openjdk that we are aware of. So for the 17.x series the known fix is 17.0.12.

[TimBrown1611]

hi @westonsteimel , thanks for your answer!

can you elaborate on the JVM cataloger? isn't it working like java cataloger? isn't github advisory more accurate?
moreover, i've posted here - https://anchorecommunity.discourse.group/t/focus-fixed-versions-on-a-cve-in-grype/242
with suggestion how we can make the results maybe more focused :)

let me know what do you think

[westonsteimel]

I'll let @wagoodman speak on the specific details of the JVM cataloguer, but the GitHub data does not include the Java jdk or jre environments, only maven like packages so it cannot be used for this.

[westonsteimel]

currently there is not a way to make the fixed version for that specific match only show 17.x because of the way all of the NVD processing works, but we are working on improving this with work that is ongoing for the grype dB v6 schema, but it is a significant amount of change compared to previous schemas so will take some time to get all of the pieces in place to start using it

[westonsteimel]

also, we do think there needs to be a way to show what the fixes are for newer release lines of a product since it may be desirable to jump to a newer release than the one you are currently on and there is no way to see this without querying the db for instance for the GitHub records. So ideally we'd have a way to show the "nearest" fix as well as a way to show all of the fixes greater than current, and eventually I'd also like a way to show the newest possible release of a package, but that is a stretch goal

[westonsteimel]

perhaps a temporary path forward could be to do version comparisons on the available fixes from the grype db and only show ones that are greater than the current package version in the results or something like that?

[westonsteimel]

So for the above match it would end up just showing 17.0.12, 21.0.4, 22.0.2

[tomersein]

hi @westonsteimel ,
here is my optional solution - #2271
can you please let me know what do you think?

[spiffcs]

@tomersein can you help me understand why you think these versions are "unrelated"? These lower versions are other fixes for the JVM that some other users might be interested in.

[tomersein]

Hi @spiffcs !
You can look at my example. my jvm version is 17.0.2, and in the "fixed" we have some versions like: "1.8.0_421", "11.0.24",

as an end user, it doesn't make any sense to upgrade to the above versions, they are out of context. I want to make the results more focused so action items can be made once a vulnerability is found.

what do you think? :)

[westonsteimel]

@spiffcs , just FYI I suggested this approach in #2264 (comment)

[westonsteimel]

We know what version of the package we've matched against, I think by default it doesn't make sense to show fixes that are < the currently installed version. This happens automatically though also somewhat accidentally today for the GitHub entries due to the way that data is structured and stored in grype db, but isn't possible for NVD. And I think in future we want to be able to display all relevant fixes that are greater than the current installed version across all package types anyways (I think this should be possible in v6 of grype db)

[willmurphyscode]

Discussion topic

Right now, Grype shows all fixed versions, even in table output:

grype/grype/presenter/table/presenter.go

Line 186 in e17dd0c

fixVersion := strings.Join(m.Vulnerability.Fix.Versions, ", ")

This is not ideal, because if a fix has been back-ported, Grype's table output will include suggestions to downgrade. I think there are a few approaches that might make sense:

1. Always print all the fixed versions and let the user choose where to upgrade or downgrade (i.e. don't change today's behavior)
2. Only display upgrades in the table output, unless no upgrade is available
3. Only display upgrades in all output, unless no upgrade is available
4. Try to guess the best upgrade, e.g. the lowest fixed version above the detected version

Of course, this could also be made configurable.

Edit: this issue is very similar to #2253; they should probably be discussed together.

Thanks for the PR @tomersein - once we've had a chance to discuss, we'll provide additional feedback on it.

[tomersein]

hi! if i can share my opinion:

• option 1 is confusing
• option 2 is not good enough since the jsons output are also used, so same results should be in the 2 outputs
• option 3 is good enough
• option 4 is the best solution! but might be more complex since we need to sort the fix array, 3 is good enough :)