pip does not verify SSL certificates

Bug #1015477 reported by Evan Broder
268
This bug affects 3 people
Affects Status Importance Assigned to Milestone
python-pip (Ubuntu)
Fix Released
Undecided
Unassigned
Lucid
Won't Fix
Undecided
Unassigned
Precise
Won't Fix
Undecided
Unassigned
Quantal
Won't Fix
Undecided
Unassigned

Bug Description

pip uses urllib2 to fetch packages, which means that it doesn't do any SSL cert verification.

At some level this is just the cost of urllib2 sucking. I wasn't able to find any prior actions from the security team on urllib2 not doing certificate validation, so I'm naively guessing that it's being accepted as the cost of doing business. But I think it's particularly concerning for pip, since it downloads and installs code onto the system.

I've attached a quickly hacked together patch that overrides httplib.HTTPConnection.connect, which is actually responsible for the SSL handshake. The added verification is backported from Python 3.2, which includes a ssl.match_hostname function.

Marking as embargoed for the time being, though that's possibly a bit silly, so feel free to change if you don't feel it merits an embargo.

(Note that it's also not possible to get pip to download over SSL from pypi - although pypi serves over SSL, its links to the actual code download are over plaintext HTTP. I ran into this while working on Stripe's code hosting site at https://code.stripe.com, which we had previously believed gave us a mechanism to securely distribute our code)

Tags: patch

CVE References

Revision history for this message
Evan Broder (broder) wrote :
Revision history for this message
Marc Deslauriers (mdeslaur) wrote :
Changed in python-pip (Ubuntu):
status: New → Incomplete
Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

Thanks for taking the time to report this bug and helping to make Ubuntu better. Since the package referred to in this bug is in universe or multiverse, it is community maintained. If you are able, I suggest coordinating with upstream and posting a debdiff for this issue. When a debdiff is available, members of the security team will review it and publish the package. See the following link for more information: https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures

visibility: private → public
tags: added: patch
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for python-pip (Ubuntu) because there has been no activity for 60 days.]

Changed in python-pip (Ubuntu):
status: Incomplete → Expired
Changed in python-pip (Ubuntu):
status: Expired → Confirmed
Revision history for this message
Donald Stufft (dstufft) wrote :

Hello there,

I've never particularly engaged the Linux Distro, much less the Ubuntu, packaging process so forgive me if I'm doing this wrong.

I'm a pip maintainer and I would like to get this fixed in Ubuntu. I see that saucy has pip 1.4.1, raring has 1.3.1, quantal has 1.1, precise has 1.0, and lucid has 0.3.1. This means that the fix is already in place for saucy and raring but that using pip in quantal, precise, and lucid essentially allows someone in the position to MITM traffic to execute arbitrary Python code (ref CVE-2013-1629).

So I'm not sure what the options are for fixing this, easiest from my point of view is to upgrade any version of pip pre 1.3 to at least pip 1.3 so that it gets TLS verification and folks are safer when using pip. Is this an option?

Revision history for this message
Barry Warsaw (barry) wrote :

You could use backports: https://help.ubuntu.com/community/UbuntuBackports but I'm not sure that will reach the widest possible audience. It may be worth doing in addition to security-only fixes, but it's a lot of effort to ensure that the package will build, install, and work on older releases. It may be easy or hard depending on pip's dependency stack.

Ideally, a security-only patch would be provided for the security pockets of these releases: https://wiki.ubuntu.com/SecurityTeam/FAQ

I don't have the cycles to create the patches, but I could review and test them.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in python-pip (Ubuntu Lucid):
status: New → Confirmed
Changed in python-pip (Ubuntu Precise):
status: New → Confirmed
Changed in python-pip (Ubuntu Quantal):
status: New → Confirmed
Changed in python-pip (Ubuntu Quantal):
status: Confirmed → Won't Fix
Revision history for this message
Stefano Rivera (stefanor) wrote :

This is of course fixed, post-precise (in 1.3)

Changed in python-pip (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Rolf Leggewie (r0lf) wrote :

lucid has seen the end of its life and is no longer receiving any updates. Marking the lucid task for this ticket as "Won't Fix".

Changed in python-pip (Ubuntu Lucid):
status: Confirmed → Won't Fix
Revision history for this message
Eduardo Barretto (ebarretto) wrote :

precise has seen the end of its life and is no longer receiving any updates.
Marking the precise task for this ticket as 'Won't Fix'.

Changed in python-pip (Ubuntu Precise):
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.