py-lmdb CVE-2019-16224, CVE-2019-16225, CVE-2019-16226, CVE-2019-16227

[douglasawh]

JFrog

CVE-2019-16224, CVE-2019-16225, CVE-2019-16226, CVE-2019-16227

v1.10.1

There is a known exploit: https://github.com/TeamSeri0us/pocs/tree/master/lmdb/lmdb%20memcpy%20illegal%20dst

py-lmdb has newer versions. It seems like just upgrading the py-lmdb package to something later would make the scans go away: https://github.com/jnwatson/py-lmdb/tags

Please let us know if any additional information is required.

[k8s-ci-robot]

This issue is currently awaiting triage.

If Ingress contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[longwuyuan]

• Copy paste your entire scanner report please
• Project will bump alpine and hence the bundled libs soon so if patches are released for these CVEs on alpine, then the next release of the controller will ship with mitigations
• We use grype a lot as that works well for the needs and there are lesser complications in getting the details of the CVEs

[douglasawh]

@longwuyuan thanks for taking a look at this!

Here's the full report:

Docker_7cbca2b_Security_Export.csv

[longwuyuan]

its hard to read. what scanner produces this. any tips on how to read it easily formatted like a report

[longwuyuan]

in any case, if py-lmdb is a python component, then its not likely in the data path of a connection between a client from outside the cluster to the pod inside the cluster. Python is not nearly anywhere at the core of the controller as some may fear. The core is mostly go & lua.

Grype does not report py-lmdb too. So if there is a patch already out there, then next release of controller will take care of it. Same for other CVEs.

There have been reports earlier and general undrestanding is that not all scanners can be the same priority so the project is mostly working with snyk and grype. These 2 point out stuff like TLS libs etc which are in direct path of the connections over ingress.

[ae185008]

its hard to read. what scanner produces this. any tips on how to read it easily formatted like a report
The vulnerability scan tool used here is https://jfrog.com/xray/ and the image scanned here is ingress-nginx version 1.10.1