Fix CPE update field handling for non-JVM packages #2845
Conversation
17efd5c to
e51a35f
Compare
- Added a new function `combineVersionAndUpdate` to handle the combination of version and update fields for various package types. - Updated the `MatchPackageByCPEs` and `filterCPEsByVersion` functions to utilize the new logic, ensuring consistent version formatting across non-JVM and JVM packages. Signed-off-by: [email protected] <[email protected]> Signed-off-by: ayham291 <[email protected]>
e51a35f to
0242bcc
Compare
…d-handling-for-non-jvm-packages
…d-handling-for-non-jvm-packages
d9be337 to
63efc89
Compare
|
Hi @ayham291, I've been doing some verification about the "right" behavior here before we make a change to version comparison -- we don't want to introduce behavior that would result in missed vulnerabilities. I think by only concatenating these values together, it will not work quite as we want, however I see a number of examples where using a dash might be the right thing. I wrote a small program to look at the CPE database for entries with updates, to inspect how some of these are represented in our database. One example is And So this should actually work correctly, too, since with a semver comparison the Would you agree with this assessment, would this cause a problem for the issue you're trying to fix? |
|
Hi @kzantow, Thank you for the thorough investigation and the examples you provided. Your observation is absolutely correct - there is indeed inconsistency in how versions are represented in the database, even within the same package. Looking at the NTP vulnerabilities, I can see that the database itself uses both formats:
Similarly, for Adobe ColdFusion and for Nextcloud with semver.
The fix is still valuable because it addresses the core problem of ignoring the update field, which was causing missed matches for the many entries that do use the concatenated format. The inconsistency in the data in the database itself means that no single approach will work perfectly for all entries. 🤷 Thanks again for the verification! |
|
I finally tracked down what's going on and it's a bit of a mess. The most important bit to note is that we are concatenating the update field with a dash when we build the db for CPE versions with updates. I see that we have one potentially incorrect record in our overrides data, given the NVD record specifies this as an update rather than part of the version. We'll get this data fixed. Because of this, I think the behavior in Grype should be to include a dash. There is a complication that some NVD records include the It's possible this concatenation is more ideal, since vs. ... the latter returns correct results, whereas we have many false negatives from the former. Additionally, it would be great to have some test cases that actually exercise matching with package(s) with updates in the CPE, rather than just testing the utility function. If you're able to add that, it would be great and would help expedite this fix. Otherwise, I'll look into getting this wrapped up after the new year. |
Fix CPE update field handling for non-JVM packages
Problem
The CPE matching logic was only considering the
updatefield for JVM packages, but it should also handle other packages where the update field contains important version information. For example, with NTP and OpenSSH:The current code would only use
4.2.8for version matching, ignoring thep18update field, which should be combined to form the complete version4.2.8p18.Solution
combineVersionAndUpdatefunction that handles CPE version and update field combinations for all package typesMatchPackageByCPEsandfilterCPEsByVersionfunctions to use the new general functiontransformJvmVersionfunctionChanges
combineVersionAndUpdatefunction ingrype/matcher/internal/cpe.goTesting
Before
After