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.18k stars 454 forks source link

fix: Location in SBOM field shows local filepath instead of location in binary #4396

Open jananir640 opened 2 weeks ago

jananir640 commented 2 weeks ago

Description

It seems that sometimes when cve-bin-tool detects the location/filepath of a dependency, it provides the path where that dependency is locally installed in the environment rather than where the dependency exists on the binary it is scanning. To my understanding, the location field is meant to help users understand where to go to patch, but the existing logic does not necessarily provide that. I see that this issue https://github.com/intel/cve-bin-tool/issues/3815 added this enhancement, so I am also wondering if this was the intended use.

To reproduce

Steps to reproduce the behaviour:

  1. scan using these flags/this config --sbom-output sbom_out.json --sbom-type cyclonedx --sbom-format json
  2. on this file https://s3.amazonaws.com/ddagent-windows-stable/ddagent-cli-7.55.2.msi
  3. then view the context of sbom_out.json

Expected behaviour: the location of openssl on the binary Actual behaviour: the SBOM shows that the location of openssl is /usr/bin/openssl whereas this is not a valid path on the binary, but rather is the path where openssl is locally installed

Version/platform info

Version of CVE-bin-tool( e.g. output of cve-bin-tool --version): v3.3.1dev0 Installed from GitHub Operating system: Linux Python version (e.g. python3 --version): 3.18.17

Anything else?

Feel free to add any other context here.

anthonyharrison commented 2 weeks ago

Thanks. I think this is a issue.

The location of the file is based on known locations of key binaries. These known locations are for a Linux based system only. . This is why /usr/bin/openssl is reported; the location has been assumed to be the location on the scanning machine.

If the binary is a Windows executable (which I assume it is), the reported location should probably be a Windows path (or not reported if scanning a Windows binary on a Linux machine)

I can't get the sample msi file to scan on my Linux system (it fails to extract) so I can't see the generated SBOM.

cc @terriko @mastersans

terriko commented 2 weeks ago

Yeah, I'm not sure why it's doing it that way now that I'm looking at this again. I would have expected it to report the filename where the issue was found, and if that file is an archive ideally we'd report the path within that archive. Probably my bad for approving it.

I guess the good news is that probably we can just replace find_product_location() with something that does the right thing?

anthonyharrison commented 2 weeks ago

The evidence should be the file which has been scanned. So we should report the archive/executable which has been scanned which contains the component which is being reported.