The urllib3 library before 1.24.2 for Python mishandles certain cases where the desired set of CA certificates is different from the OS store of CA certificates, which results in SSL connections succeeding in situations where a verification failure is the correct outcome. This is related to use of the ssl_context, ca_certs, or ca_certs_dir argument. Upstream patch: https://github.com/urllib3/urllib3/compare/a6ec68a...1efadf4 References: https://www.openwall.com/lists/oss-security/2019/04/17/3
Created python-urllib3 tracking bugs for this issue: Affects: fedora-all [bug 1702474] Created python3-urllib3 tracking bugs for this issue: Affects: epel-all [bug 1702475]
Created python-urllib3 tracking bugs for this issue: Affects: openstack-rdo [bug 1707999]
External References: https://www.openwall.com/lists/oss-security/2019/04/17/3
Created python-urllib3 tracking bugs for this issue: Affects: fedora-all [bug 1724437]
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2019:3335 https://access.redhat.com/errata/RHSA-2019:3335
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2019:3590 https://access.redhat.com/errata/RHSA-2019:3590
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2019-11324
The automatic unconditional loading of system CA certificates was added in version 1.17 via this commit: https://github.com/urllib3/urllib3/commit/0d06f4e9a320e9d39fbedc4e9ff0d1cf8622a965 The upstream patch linked in comment 0 also includes change other than the fix for this issue. The part relevant to this CVE is: https://github.com/urllib3/urllib3/commit/1efadf43dc63317cd9eaa3e0fdb9e05ab07254b1#diff-7c9a38cd64066636d0e73a2449a28640L330
Created python-pip tracking bugs for this issue: Affects: fedora-all [bug 1774595]
Created python-virtualenv tracking bugs for this issue: Affects: fedora-30 [bug 1778099]
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2020:0850 https://access.redhat.com/errata/RHSA-2020:0850
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2020:1605 https://access.redhat.com/errata/RHSA-2020:1605
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2020:1916 https://access.redhat.com/errata/RHSA-2020:1916
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2020:2068 https://access.redhat.com/errata/RHSA-2020:2068
Mitigation: The urllib3 package is used by elastic-curator, which is deployed in the ose-logging-curator, and used by the optional logging feature in OpenShift Container Platform (OCP). Therefore OCP 3.11 users can mitigate this issue by not deploying and using the Curator logging feature. In OCP 4 urllib3 is also used by several Ansible Play Book images built with the Operator SDK and available for installation in OCP 4 including openshift-enterprise-ansible-operator and ose-metering-ansible-operator. Therefore those operators should not be deployed in order to mitigate this issue in OCP 4.
Statement: This issue did not affect the versions of python-urllib3 as shipped with Red Hat Enterprise Linux 6, and 7 as the older code shipped there did not load the system certificates. Red Hat Satellite 6.2 is on Maintenance Support 2 phase, hence only selected Critical and Important issues will be fixed. Please refer to Red Hat Satellite Product Life Cycle page for more information. In Red Hat OpenStack Platform 13, because the flaw has a lower impact and the fix would require a substantial amount of development, no update will be provided at this time for the RHOSP python-urllib3 package.