CVE-2021-41254 not detected

[javixeneize]

Hi

I am scanning this container, ghcr.io/fluxcd/kustomize-controller:v0.9.1, with trivy.

Last week a vulnerability was reported in flux, https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-41254, and i believe this image is affected by that vulnerability. However, trivy doesnt flag that CVE in this image

Is this something that should have been detected?

Thanks

[knqyf263]

@rahul2393 Could you take a look?

[rahul2393]

Thank you for helping improve Trivy! Trivy uses multiple threat intelligence feeds for its scanning. It seems like one of the feeds "GitHub Advisory Database" has a false negative. Can you please open an issue on their support community and add a reference here? https://github.community/

cc: @javixeneize There is no advisory for CVE-2021-41254 in GHSA https://github.com/advisories?query=ecosystem%3Ago+CVE-2021-41254

[javixeneize]

Thanks @rahul2393

Looks like the advisory is released now - https://github.com/advisories/GHSA-35rf-v2jv-gfg7 But trivy still cant detect it

Thanks

[javixeneize]

@rahul2393 @knqyf263 any update on this?

[rahul2393]

Hello @javixeneize sorry for delay, will be creating the PR shortly for this.

[javixeneize]

Thanks!

[rahul2393]

Hello, @javixeneize on further investigation we found that today we don't have any way to extract the binary version information for kustomize-controller, we can parse the library dependencies and version of a Golang binary but not the binary version. So trivy can't scan the binary itself. Please let us know if you have any ideas Thanks

[javixeneize]

Hi

Maybe checking the hash of the binary? Don’t know how much it would affect the performance though

[rahul2393]

Can you elaborate more on how the hash of binary relate to github version, because for vulnerability checking we compare the advisory version with binary/lib version

[javixeneize]

Yeah, it will imply a change in the way on how you detect vulnerabilities. On top of checking library+version, it would require to have a database of hashes of vulnerable binaries and the binary name. when that binary is found, check it’s hash against the database.

It is not pretty but it’s the only way I can think of detecting the vulnerable binary.

the other option would be to assume that this image contains kustomize 0.9.1 based on the name, and flag the image as vulnerable

[knqyf263]

@javixeneize Thanks for your idea.

On top of checking library+version, it would require to have a database of hashes of vulnerable binaries and the binary name.

We tried it, but the database will be quite large as every binary has different hashes even with different compile options. It is difficult to maintain such a database by us. If there is a public database, we can support it.

the other option would be to assume that this image contains kustomize 0.9.1 based on the name, and flag the image as vulnerable

There is a lot of software with similar names. It leads to false positives. Also, we cannot know the base image name once the custom image is built on top of the base image.

[javixeneize]

Yeah I have seen it with dependency check. Not an easy solution then. Hopefully somebody can bring a better idea

[github-actions[bot]]

This issue is stale because it has been labeled with inactivity.