Botocore: Use of urllib3 exposed to vulnerability CVE2018-20060

Created on 28 Mar 2019  路  8Comments  路  Source: boto/botocore

Hey,
I see that you're keeping urllib3 for legacy reasons https://github.com/boto/botocore/issues/1613.
We use your boto3 lib and found out that its opening our code (and anyone else who is including botocore) to a high severity vulnerability CVE2018-20060

Please could you reconsider removing (or updating) this library, to remove the vulnerability?

Most helpful comment

@JordonPhillips,

According to @joguSD in aws/aws-cli#4082 --

The only usage of this vendored package is extending the exception classes in case customers were using the vendored exceptions in try/excepts.

Since the usage is so basic here, is there any reason not to update urllib3 to an unaffected version, verify that the exception still works, and include the change in a maintenance release? I understand that the package is unaffected by the actual vulnerability, but it does raise flags and, e.g. with aquasecurity/kube-hunter#112, that can cause minor headaches.

All 8 comments

It only opens your code to vulnerabilities if you are using it. If you are using the documented interface of botocore then you're fine. botocore does not and will not use it, so botocore / boto3 / cli usage does not expose you to those vulnerabilities.

We plan on removing that code in our next major version bump.

Do you know when that major version bump is planned? It does show up as a high-sev vulnerability in container image scans.

I don't consider myself an expert on vendored python modules, but I believe aws-cli may be unintentionally importing the vendored urllib3 from botocore via this line here:

https://github.com/aws/aws-cli/blob/develop/awscli/customizations/configure/__init__.py#L14

Probably the aws-cli issues is a better place for this but I thought I'd drop a note here, too.

I will file a report with the aws-cli issue tracker and hopefully someone can comment on whether there is an issue or not.

Also this issue seems to be essentially very similar to #1608.

@JordonPhillips,

According to @joguSD in aws/aws-cli#4082 --

The only usage of this vendored package is extending the exception classes in case customers were using the vendored exceptions in try/excepts.

Since the usage is so basic here, is there any reason not to update urllib3 to an unaffected version, verify that the exception still works, and include the change in a maintenance release? I understand that the package is unaffected by the actual vulnerability, but it does raise flags and, e.g. with aquasecurity/kube-hunter#112, that can cause minor headaches.

Right, this is currently our most common "high-severity" CVE reported across our containers. Having to make lots of exceptions & triple check that it really isn't used.

We don't vendor urllib3 directly anymore and allow up to the latest release. I'm going to resolve this since we shouldn't be exposing any of these issues in a current release.

鈿狅笍COMMENT VISIBILITY WARNING鈿狅笍

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

Was this page helpful?
0 / 5 - 0 ratings