search

intel / cve-bin-tool

The CVE Binary Tool helps you determine if your system includes known vulnerabilities. You can scan binaries for over 200 common, vulnerable components (openssl, libpng, libxml2, expat and others), or if you know the components used, you can get a list of known vulnerabilities associated with an SBOM or a list of components and versions.
https://cve-bin-tool.readthedocs.io/en/latest/
GNU General Public License v3.0
1.24k stars 465 forks source link

v3.4 excludes micro-ecc when version is "1" instead of "1.0" which worked in 3.3 #4467

Open tzirn opened 2 months ago

tzirn commented 2 months ago

Description

@terriko requested I open a new bug report:

in v3.4 of this tool when the micro-ecc version is set at 1 in the SBOM CSV file (because Excel keeps changing 1.0 to 1 before the CSV is saved) the tool doesnt find the micro-ecc vulnerability at all even though it's in our triage input file. This was found to be due to the fact that it was not 1.0 However, as I said this worked in v3.3 so users didnt have to fight with excel to constantly re-force it to 1.0. This was found when testing v4.4 in this bug report: micrium uC/Lib vulnerability causes cve-bin-tool to delete triage response data from triage input file

To reproduce

Steps to reproduce the behavior:

  1. have a CSV SBOM with a product that has a known issue in a main version (like 1.0, 2.0, etc)
  2. in this SBOM store the version as an integer without decimal places, so 1, or 2, etc
  3. run the cve-bin-tool and see the output report doesnt contain the known issue

Expected behavior: to list the known issue as the tool did in v3.3 Actual behavior: the output report doesnt contain the known issue

Version/platform info

Version of CVE-bin-tool( e.g. output of cve-bin-tool --version): 3.4 Installed from pypi or github? Operating system: Linux/Windows: Windows 10

Anything else?

Feel free to add any other context here. You can get the files I used from the bug report linked at the beginning here

terriko commented 2 months ago

So, my guess is what happened here is that it's a side effect of having to move away from the old version compare library. The old library had moved to more PEP440 compliance and was rejecting anything that didn't comply with that format (which is a HUGE number of versions in the overall database). So there's no chance of going back; it would break a lot of things.

At a guess, the problem is either that we're doing a string compare so "1" != "1.0" for the basic equals case or that the comparison code is saying that the two items have different length of arguments so therefore they can't be the same. Given that this came up due to excel's over-zealous number handling, my guess is that it's only going to happen with versions that are XXX.0 so that may be easy to add in as a special case.

The question is whether anyone actually does mean XXX.0 to not be the same as XXX, but I don't think I've seen that in the data yet. My instinct is that we should fix this and then be prepared to re-work only if it turns out to be a problem.

terriko commented 3 weeks ago

@tzirn got a fix for you in https://github.com/intel/cve-bin-tool/pull/4543 if you want to test it!

tzirn commented 3 weeks ago

@tzirn got a fix for you in #4543 if you want to test it!

Yes I'll test it next week - I was super busy this week