Ambassador: Non-OS Package Type (python) Critical Vulnerabilities Against Ambassador:1.5.5

[dfl-erik]

Describe the bug
There are 2 critical vulnerabilities against datawire/ambassador:1.5.5

1. CRITICAL Vulnerability found in non-os package type (python) - /usr/lib/python3.7/site-packages/PyYAML (CVE-2019-20477 - https://nvd.nist.gov/vuln/detail/CVE-2019-20477)
2. CRITICAL Vulnerability found in non-os package type (python) - /usr/lib/python3.7/site-packages/PyYAML (CVE-2020-1747 - https://nvd.nist.gov/vuln/detail/CVE-2020-1747)

To Reproduce

1. Build image from datawire/ambassador:1.5.5
2. Scan image with Anchore

Expected behavior
Vulnerabilities should be remediated in ambassador:1.5.5

Versions (please complete the following information):

• Ambassador: 1.5.5
  
  
  
  • Docker - 19.03.12
  
  
  • Anchore inline scan 0.7.0
  
  

Additional context

[kflynn]

Thanks for filing this! We will be upgrading the PyYAML package in our next release (v1.7.0, in a few weeks) to address the scan, but we've been careful to only use PyYAML's safe loader & dumper, so Ambassador is not actually vulnerable to these CVEs. 🙂

[kflynn]

Oh dear -- I meant to leave this open to track the upgrade.

[dfl-erik]

@kflynn any clue if 1.7.0 will address CVE-2020-1967 against libcrypto1.1 and CVE-2020-1967 against libssl1.1? Both of these vulnerabilities are fixed in updates to their respective packages.

Thanks

[kflynn]

@dfl-erik Yes, my plan is to do a walk over all the dependencies for updates. Did your scanner point out any others? Thanks!

[kflynn]

Further notes on CVE-2020-1967:

Ambassador definitely does a lot of TLS-related things. 🙂 However, none of them use OpenSSL to implement the TLS network protocol, so Ambassador is not vulnerable to CVE-2020-1967, though we're going to update the libraries anyway.

• The data-plane side of Ambassador makes heavy use of TLS connections handled by Envoy. Envoy uses BoringSSL for this rather than OpenSSL.
• The documentation for Ambassador references the openssl(1) command for certificate generation. This is not running the TLS network protocol.
• The control-plane side of Ambassador Edge Stack can use the TLS network protocol to request certificates from ACME servers. This uses the internal Golang TLS client rather than OpenSSL.

[dfl-erik]

@kflynn The only only vulnerability our scanner picked up was CVE-2020-14422 against python3, but it appears that has already been fixed in later versions of ambassador (I checked 1.6.2 and the vulnerability did not show up).

Thank you so much for the quick replies and thorough explanations.

[kflynn]

@dfl-erik Whew, glad to hear it. 🙂 Thanks for the reports! 🙂

[khussey]

The dependency versions have been updated and will be shipped as part of the upcoming 1.7.0 release.

[dfl-erik]

Congrats on getting 1.7.0 shipped. Unfortunately when I scan the new version with the anchore inline scanner I'm now seeing vulnerability CVE-2016-7037 against python. So this is a different vulnerability than we were seeing in version 1.6.2, but it's the same type of vulnerability that we were unable to resolve previously.

[kflynn]

@dfl-erik Hm. Could you re-check that CVE number? CVE-2016-7037 seems to be talking about a PHP issue, so I'm a little confused. 🙂

[dfl-erik]

This is the result from the scan:
HIGH Vulnerability found in non-os package type (python) - /usr/lib/python3.7/site-packages/jwt (CVE-2016-7037 - https://nvd.nist.gov/vuln/detail/CVE-2016-7037

Thank you kflynn

[khussey]

Thanks for scanning again with 1.7.0 so quickly @dfl-erik! Since the vulnerabilities originally reported against 1.5.5 have been addressed, please open a separate issue for the results of the scan of 1.7.0 and we'll assess it right away!