[Catalog-sig] [DRAFT] Proposal for fixing PyPI/pip security

[Giovanni Bajo]

Il giorno 10/feb/2013, alle ore 14:43, Nick Coghlan <ncoghlan at gmail.com> ha scritto:

> On Sun, Feb 10, 2013 at 11:30 PM, Giovanni Bajo <rasky at develer.com> wrote:
>> This is by far the biggest problem to be solved, and my document brings a proposal here. It would be great if the TUF guys reviewed it.
> 
> Ensuring we fully address the problems that are addressed by TUF is
> more important than the question of whether or not we use the TUF
> software itself. However, the concern I have with your proposal is
> that I saw zero information regarding how it deals with attackers
> supplying old versions of software,

It's true that it's something that my document doesn't cover, but there is a reason.

The way TUF handles it, is through an automatic signing of a file called "timestamp.txt", using a fast expiring signature. This files basically contains (simplifying) a reference to the latest version of the software. Since the signature expires, an attacker cannot replay it.

On PyPI, a maintainer is able to decide which is the current/available set of releases of a packages through the web interface of PyPI. This means that the maintainer can click a few buttons on the web UI, and the timestamp.txt should change to its desire, including reviving an old version of the software. So in a way, we're offering a feature that already *breaks* the feature that TUF is trying to protect against. An attacker with the user's PyPI password can revive any old version of the software.

In the TUF complete model, this is less of an issue because all commands "release this", "unrelease this" are made through GPG-validated signatures. So to fully implement this, we would also need to modify setup.py to offer any package release management feature of PyPI.

TL;DR: an integration of TUF doens't "magically" fix the replay attack of older versions, unless we also specifically modify distutils to include package management administrative commands to it, with GPG validation/signing, and we expose the corresponding webserver API from PyPI. We still need a design here.

NOTE: within my proposal, an attacker with write access to the PyPI file storage area can't do a replay attack; in fact, even if it overwrites the contents of django-1.1.2.tar.gz{,.sig} with django-1.1.1.tar.gz{,.sig}, and even if the signature would be verified, the package metadata will show the 1.1.1 version, and thus pip would be able to detect the attack. I've clarified this in my document.

> or, indeed, any description of the
> threat model at all.

Can you please elaborate on what you expect to find as "thread model"? Every task in my document that is supposed to give an enhanced security explicitly lists the possible attacks that are prevented by implementing the task. This is my definition of "threat model", but maybe you are thinking of something different. 

Or maybe you would prefer to see all those sections together at the beginning of the document?

> The parts of your proposal that I believe need to
> be closely reviewed are:
> - GPG vs PKCS#1

Do you have any specific open-source multi-platform implementation of PCKS#1 in mind? I think we don't want to write our own crypto here, especially since PCKS#1 is *really* tricky.

> - your custom trust model vs TUF target delegation
> - any threats that TUF covers and your proposal does not

To do this, we first need a proposal from TUF authors on how they plan to integrate it with pip/PyPI. On their website, there is (was) a preliminary document on this, but it just scratched the surface.

Let me stress agan that TUF is just a component of the solution, because it's not a design for a package manager, just for a single-software update. There are important differences in how trust is handled (eg: for a specific software, you can embed the trust in the first version, and upgrade from there), while in a package manager the idea is that the user always starts with no trust on any package, but it still wants to install software given only its name.
-- 
Giovanni Bajo   ::  rasky at develer.com
Develer S.r.l.  ::  http://www.develer.com

My Blog: http://giovanni.bajo.it




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4346 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20130210/26cec65d/attachment.bin>