Red Hat Bugzilla – Bug 994182
CVE-2013-1633 python-setuptools: easy_install insecure installation mechanism
Last modified: 2016-09-19 22:49:07 EDT
Common Vulnerabilities and Exposures assigned an identifier CVE-2013-1633 to
the following vulnerability:
easy_install in setuptools before 0.7 uses HTTP to retrieve packages
from the PyPI repository, and does not perform integrity checks on
package contents, which allows man-in-the-middle attackers to execute
arbitrary code via a crafted response to the default use of the
Will also affect python-virtualenv which currently bundles setuptools.
Question -- is this something that we should be pushing the fixed package back into older Fedora releases? The new setuptools is mostly compatible although we've had to fix a few packages for use with it. Currently, I know of:
* python-RPi-GPIO which uses a technique for bootstrapping its build system that relied on distribute. The solution was to get rid of the bootstrap code as it's not needed if we have system packages for python-setuptools. This could apply to other packages as well.
* python-zc-buildout. Fixing this required updating to a newer version of buildout. Should not be a generalized problem for other packages.
Define "older Fedora releases". We only support Fedora 18 and 19 right now. Is it not possible to update this in those two versions?
I'll also file tracking bugs, sorry I forgot to do that.
Created python-virtualenv tracking bugs for this issue:
Affects: fedora-all [bug 994773]
Affects: epel-all [bug 994774]
Created python-setuptools tracking bugs for this issue:
Affects: fedora-all [bug 994772]
Vincent, does this also affect python-setuptools as shipped in RHEL 5 and RHEL 6? If so, would you open the bugs for them, too?
@slavek: It will affect RHEL5 and RHEL6. The feature (using https and checking the server's certificate) wasn't implemented until setuptools-0.7. RHEL6 is on setuptools-0.6.x (really, the distribute fork of setuptools). RHEL5 is older than that. If you're backporting or looking at the minimum version to upgrade to, also be aware that there is a CVE in the code that implements the feature so you'll also need to backport the changes that went into 0.9.5: https://pypi.python.org/pypi/setuptools/0.9.8#id115
@vincent: Yeah, Fedora rawhide (F20) has a Fedora Change Plan to make the upgrade from 0.6.x to 0.7+: https://fedoraproject.org/wiki/Changes/Python_setuptools_0.7
All previous versions of Fedora are on the 0.6.x release series. It is possible to upgrade and as I said in Comment2, in Rawhide it so far has only caused a few known incompatibilities. However, there are widespread changes to the codebase due to the nature of the upstream work and in Rawhide we have the freedom to upgrade other packages that depend heavily on setuptools so it would be nice to avoid upgrading.
One option is if slavek is going to backport the changes needed to the RHEL package, we could consume that same patch in Fedora 17 and 18 instead of upgrading to the latest version.
There was no plan to do an erratum at this time for RHEL5 and 6, however if you want to help Toshio (or vice versa) but together something that will work on Fedora so we can analyze any potential impact, that would be extremely helpful.
There's probably a dozen packages that I can see in RHEL6 that depend on python-setuptools, and none in RHEL5 so the impact there should be minimal. For reference, for RHEL6 I see:
Do you think that helping deal with Fedora would be a reasonable way forward? The work wouldn't be in vain.
python-virtualenv-1.10.1-1.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
python-virtualenv-1.10.1-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
Another compatibility note: the easy_install commandline tool changed in 0.7.x to install zipped eggs instead of unzipped eggs by default. This caused a small change in packaging guidelines (adding the -Z CLI switch to restore the old behaviour) in corner cases. Not really known how much this would affect end user's use of the easy_install command.
Red Hat OpenShift Enterprise 1.2 is now in Production 1 Phase of the support and maintenance life cycle. This has been rated as having Moderate security impact and is not currently planned to be addressed in future updates. For additional information, refer to the Red Hat OpenShift Enterprise Life Cycle: https://access.redhat.com/site/support/policy/updates/openshift.