oss-sec mailing list archives

Re: Requesting CVE-ID(s) for Python's pip


From: Kurt Seifried <kseifried () redhat com>
Date: Tue, 30 Jul 2013 00:29:38 -0600

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/26/2013 09:46 AM, Donald Stufft wrote:

On Jul 26, 2013, at 8:03 AM, isis agora lovecruft
<isis () torproject org> wrote:

I would also like to request CVE assignment(s) for two issues in
pip (https://github.com/pypa/pip/), related to Donald Stufft's.

First issue: ------------ Python's pip versions 1.4.x and earlier
are vulnerable to an Arbitrary Code Execution Attack due to
incorrect regexp parsing of external download links in the
following functions in pip/index.py:

* PackageFinder._get_pages()
https://github.com/pypa/pip/blob/1.3.X/pip/index.py#L232 *
PackageFinder._sort_links()
https://github.com/pypa/pip/blob/1.3.X/pip/index.py#L272 *
PackageFinder._package_versions()
https://github.com/pypa/pip/blob/1.3.X/pip/index.py#L285 *
PackageFinder._link_package_versions()
https://github.com/pypa/pip/blob/1.3.X/pip/index.py#L290

Which allow an attacker with the ability to Man-in-the-Middle
external package URIs (which often include external HTTP URIs,
and can include the module author's personal website, see 
https://github.com/pypa/pip/commit/a3584d176697bd4c83390de1857679d44389e00d#L0L265)


to specify an arbitrarily high package version number and gain code
execution.

Uptream bugtracker reports:
https://github.com/pypa/pip/issues/425#issuecomment-20639993 
https://github.com/pypa/pip/issues/425#issuecomment-20640890

Other mentions:
https://github.com/pypa/pip/commit/9ccd5f0bb37508f03e6a19be58af7384eede2157


https://paste.debian.net/7309/

This issue is fixed in pip>=1.5.x by Donald Stufft in the
following commits: 
https://github.com/pypa/pip/commit/0e1da584f418ae0088b43d01248572e2ff53d3a1


https://github.com/pypa/pip/commit/9ccd5f0bb37508f03e6a19be58af7384eede2157

I'm not sure I understand this one. Is this just the external urls?
Technically it wasn't a problem with the regexp's they worked fine.
It was just bad behavior inherited from legacy systems. 1.4.x
defaults to allowing them but enables people to turn them off,
1.5.x will disallow them by default.

1.3.x and earlier allowed them and offered no way to disable them.

So it sounds like 1.3.x was definitely vulnerable to this with no way
to disable it, 1.4 was vulnerable by default but could be made safe,
and 1.5 is vulnerable but safe by default, is that correct?


Second issue: ------------- Python's pip versions 1.5.x and
earlier use MD5 hashes for verification of package integrity
against PyPI (which defaults to providing MD5).

Strictly speaking pip doesn't default to any hash. It just uses the
hash given to it. Prior to 1.2 it only allowed MD5 but since the
release of 1.2 it has allowed any of the guaranteed hashes in
python's hash lib.

See: https://github.com/pypa/pip/pull/467

Setuptools has also historically only allowed MD5 but has recently
with version 0.9+ enabled similar abilities to setuptools to enable
the use of any available hashes as well. Distribute (a fork of
setuptools which has now been merged back into setuptools) only
supports MD5 in it's older releases.

I'm not sure in this case MD5 alone is a security vulnerability, I
think previously it had been decided that just because it uses MD5
wasn't ernough to get a CVE, it had to have some specific use that
made MD5 a problem. OTOH DES is at this point worthy of a CVE since
you can crack it in a reasonable amount of time on AWS/etc for a few
hundred bucks or less. Personally I would assign a CVE to everything
using MD5 by default to try and help kill it off, but that would be a
lot of CVEs.


----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B
7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)

iQIcBAEBAgAGBQJR911SAAoJEBYNRVNeJnmTViYQALHzY4DGMcJJRl6Fj6kU5HHl
H2Ck/4uNH6a1q95jy/MFNja2MiUrMlqay2FJ2G+2pOmCnxf81DjFLkHnjZb4/8XU
rxiIsbZmMl0saoL3/smxX4oImDdaB7OuNNQ5/yOzMKJxjDdEhpBUc5sWtABNbKZw
CXWmsrgdVRluRWBjn5IwUua+1D+5KddiYaTvbKNkT2UYqHa/k00Ra2S8oA8dW2PF
Zladxs6Y+7PZK/7EP+3ADlzKwxxuLPh8eZVSLwAqu0DMk/nnM6U1pPS+cjKVKHgi
Pp0bTMCzkGrLTJH2wwmwLSGvg8mbm7xf0XAprYRhLs7gVKXvZXuB99BqLQ0gBR4P
VrfoTL2Rn+ZeLtlxWeI1Ra/nWmuxu1Tg3DxwKPb4tbDBEkFKtmUgNjRBxho2/s/x
nZgrHt/F7+Nt6Y8MHVYi6ijNGTv1dOREl97tj2kHa+kQxF0mJyymJEFS4Be5bj38
HroCxQFjpF3ymhZ5NTavoQ0CQg31Hey9PTQBBPhoZ7GK1JyLaEJtTQK5mNHWT2Rv
KOxz5frh+/iy1k1Z/xERC5AUkyZkbIevvpY+0eO3n5lCVcjtDXc+0zz5J/c6YkJl
ngEGZ69CWLffzlCXIjciNYLquNWbdPwQhJS8c6fbCOAeaK74b3xOHWsCnQO1ruw7
+ucujVQ2caHeU84axyOk
=dj3J
-----END PGP SIGNATURE-----


Current thread: