list of unrelated versions in the remediation #2264

TimBrown1611 · 2024-11-17T09:47:54Z

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:

since it is an image, why we are using NVD as a source, which most of the times is less reliable?
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

The text was updated successfully, but these errors were encountered:

westonsteimel · 2024-11-17T13:46:08Z

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 · 2024-11-17T13:52:31Z

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 · 2024-11-17T14:16:04Z

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 · 2024-11-17T14:18:37Z

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 · 2024-11-17T14:22:30Z

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 · 2024-11-17T14:28:42Z

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 · 2024-11-17T14:31:07Z

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

tomersein · 2024-11-20T12:37:55Z

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

spiffcs · 2024-11-20T15:17:14Z

@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 · 2024-11-20T15:23:40Z

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 · 2024-11-20T16:06:21Z

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

westonsteimel · 2024-11-20T16:09:15Z

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 · 2024-11-25T15:50:30Z

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:

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

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 · 2024-11-25T16:53:52Z

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 :)

wagoodman · 2024-12-05T20:35:55Z

dropping a little more context for this CVE in the description

select version_constraint,fixed_in_versions from vulnerability where id == "CVE-2024-21147" and namespace == "nvd:cpe";
+------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------+
| version_constraint                                                                                                           | fixed_in_versions                                             |
+------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------+
| < 20.3.15 || >= 21-ea, < 21.3.11                                                                                             | ["20.3.15","21.3.11"]                                         |
| < 17.0.12 || >= 18-ea, < 21.0.4 || >= 22-ea, < 22.0.2                                                                        | ["17.0.12","21.0.4","22.0.2"]                                 |
| < 17.0.12 || >= 18-ea, < 21.0.4 || >= 22-ea, < 22.0.2                                                                        | ["17.0.12","21.0.4","22.0.2"]                                 |
| < 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 | ["1.8.0_421","11.0.24","17.0.12","21.0.4","22.0.2","8.0.421"] |
| < 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 | ["1.8.0_421","11.0.24","17.0.12","21.0.4","22.0.2","8.0.421"] |
| < 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 | ["1.8.0_421","11.0.24","17.0.12","21.0.4","22.0.2","8.0.421"] |
| < 1.8.0_422 || >= 1.9-ea, < 8.0.422 || >= 9-ea, < 11.0.24 || >= 12-ea, < 17.0.12 || >= 18-ea, < 21.0.4 || >= 22-ea, < 22.0.2 | ["1.8.0_422","11.0.24","17.0.12","21.0.4","22.0.2","8.0.422"] |
+------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------+

wagoodman · 2024-12-05T20:41:16Z

per the livestream:

folks using the JSON output would probably also like to see the "best" upgrade
there could be configurable options here for "suggest downgrades" or "ignore extra fixes for other major versions"
at least by default highlighting/annotating the best upgrade in the table output would be useful

tomersein · 2024-12-05T20:46:55Z

Hello!

agree, is adding another field to grype schema sounds logical?
sounds ok, add it to the PR?
I am consuming the JSON, so in this case it will be less useful for me :(

thanks a lot!

per the livestream:

folks using the JSON output would probably also like to see the "best" upgrade

there could be configurable options here for "suggest downgrades" or "ignore extra fixes for other major versions"

at least by default highlighting/annotating the best upgrade in the table output would be useful

tomersein · 2024-12-07T06:38:09Z

maybe sorting the array in specific way will be a good solution?
the 1st value will be the "best upgrade" and the irrelevant versions will be last in the array?

willmurphyscode · 2024-12-12T20:47:33Z

We agree that sorting these values is the best approach
It's important that the sort be deterministic - repeatedly re-running grype should produce the same order (assuming data has not changed)
We should sort the whole set of fixed ins, trying to put better ones first.

tomersein · 2024-12-13T14:18:58Z

hi @willmurphyscode !
made the changes in the PR,
now the 1st result is the best upgrade.
for example:
Before:
jdk 17.0.2 1.8.0_401, 11.0.22, 17.0.10, 21.0.2, 8.0.401 binary CVE-2024-20945 Medium
Now:
jdk 17.0.2 17.0.10, 21.0.2, 1.8.0_401, 11.0.22, 8.0.401 binary CVE-2024-20945 Medium

tomersein · 2024-12-20T15:27:34Z

hi, regarding the last OSS gardening (asked not to sort the list):
what do you think on adding a new field under "fix" named "suggestion" like this:

        "fix": {
          "versions": [
            "1.8.0_421",
            "11.0.24",
            "17.0.12",
            "21.0.4",
            "22.0.2",
            "8.0.421"
          ],
          "state": "fixed"
          "suggestion": "17.0.12"
        },

@willmurphyscode @wagoodman

willmurphyscode · 2025-01-03T15:39:31Z

Hi @tomersein thanks for the suggestion. We think this should be added under matchDetails, and not under vulnerability in the match.

Right now, there are basically 3 items in a "match":

The vulnerability. This is upstream data - we're just saying something like, "NVD says version X, Y, and Z are vulnerable, and here's a link."
The package. From Grype's perspective, this is also upstream data. We're just saying, "The SBOM says you have Package A at version X."
The match details. This is where Grype is adding data. In other words, this is where Grype is talking about data that is relevant to both the package and the vulnerability.

The "suggestion" field is a property of the matchDetails, because it depends on both the vulnerability and the input. Probably the full path in the JSON should be something like matches[N].matchDetails[N].suggestedFixedVersion or similar.

tomersein · 2025-01-04T19:58:26Z

Hi @tomersein thanks for the suggestion. We think this should be added under matchDetails, and not under vulnerability in the match.

Right now, there are basically 3 items in a "match":

The vulnerability. This is upstream data - we're just saying something like, "NVD says version X, Y, and Z are vulnerable, and here's a link."

The package. From Grype's perspective, this is also upstream data. We're just saying, "The SBOM says you have Package A at version X."

The match details. This is where Grype is adding data. In other words, this is where Grype is talking about data that is relevant to both the package and the vulnerability.

The "suggestion" field is a property of the matchDetails, because it depends on both the vulnerability and the input. Probably the full path in the JSON should be something like matches[N].matchDetails[N].suggestedFixedVersion or similar.

Hi! @willmurphyscode
made some changes in the PR.
Hopefully this time I'm in the right direction :)

TimBrown1611 added the bug Something isn't working label Nov 17, 2024

anchoretoolsops added this to OSS Nov 17, 2024

tomersein mentioned this issue Nov 20, 2024

add suggested fixed version #2271

Open

willmurphyscode added the needs-discussion label Nov 25, 2024

willmurphyscode mentioned this issue Nov 25, 2024

Incorrect cve fixed-in version coming in grype output #2253

Open

willmurphyscode self-assigned this Dec 17, 2024

willmurphyscode moved this to In Progress in OSS Dec 17, 2024

willmurphyscode moved this from In Progress to In Review in OSS Jan 6, 2025

willmurphyscode removed the needs-discussion label Jan 6, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

list of unrelated versions in the remediation #2264

list of unrelated versions in the remediation #2264

TimBrown1611 commented Nov 17, 2024

westonsteimel commented Nov 17, 2024

TimBrown1611 commented Nov 17, 2024

westonsteimel commented Nov 17, 2024

westonsteimel commented Nov 17, 2024

westonsteimel commented Nov 17, 2024

westonsteimel commented Nov 17, 2024

westonsteimel commented Nov 17, 2024

tomersein commented Nov 20, 2024

spiffcs commented Nov 20, 2024

tomersein commented Nov 20, 2024

westonsteimel commented Nov 20, 2024

westonsteimel commented Nov 20, 2024 •

edited

Loading

willmurphyscode commented Nov 25, 2024 •

edited

Loading

tomersein commented Nov 25, 2024

wagoodman commented Dec 5, 2024

wagoodman commented Dec 5, 2024

tomersein commented Dec 5, 2024

tomersein commented Dec 7, 2024

willmurphyscode commented Dec 12, 2024

tomersein commented Dec 13, 2024

tomersein commented Dec 20, 2024

willmurphyscode commented Jan 3, 2025

tomersein commented Jan 4, 2025

list of unrelated versions in the remediation #2264

list of unrelated versions in the remediation #2264

Comments

TimBrown1611 commented Nov 17, 2024

westonsteimel commented Nov 17, 2024

TimBrown1611 commented Nov 17, 2024

westonsteimel commented Nov 17, 2024

westonsteimel commented Nov 17, 2024

westonsteimel commented Nov 17, 2024

westonsteimel commented Nov 17, 2024

westonsteimel commented Nov 17, 2024

tomersein commented Nov 20, 2024

spiffcs commented Nov 20, 2024

tomersein commented Nov 20, 2024

westonsteimel commented Nov 20, 2024

westonsteimel commented Nov 20, 2024 • edited Loading

willmurphyscode commented Nov 25, 2024 • edited Loading

Discussion topic

tomersein commented Nov 25, 2024

wagoodman commented Dec 5, 2024

wagoodman commented Dec 5, 2024

tomersein commented Dec 5, 2024

tomersein commented Dec 7, 2024

willmurphyscode commented Dec 12, 2024

tomersein commented Dec 13, 2024

tomersein commented Dec 20, 2024

willmurphyscode commented Jan 3, 2025

tomersein commented Jan 4, 2025

westonsteimel commented Nov 20, 2024 •

edited

Loading

willmurphyscode commented Nov 25, 2024 •

edited

Loading