Open douglasawh opened 3 weeks ago
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.
@longwuyuan thanks for taking a look at this!
Here's the full report:
its hard to read. what scanner produces this. any tips on how to read it easily formatted like a report
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.
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
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.