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

[Justin Cappos]

So we obviously have egg on our face about the domain expiry.   Our sys
admin should be fixing this now.

I'm a bit crunched for time with other deadlines right now, but one quick
thing I'd like to correct is that TUF works with package managers /
metadata, etc.   TUF certainly handles package managers and appropriately
protects their metadata, which in turn makes sure that dependency
resolution is secure, etc.

TUF does also prevent against replay attacks on old package versions (or at
least those that were not valid within the lifetime of the timestamp.txt
file and aren't earlier than the last time the user fetched a package.)
Note that TUF does not preclude you from asking for foo-1.0 when foo-1.1
was released if there is a valid signed version of foo-1.0.   It just makes
sure that if you ask for foo you get foo-1.1.

I'll be happy to give a detailed look at the other proposal before PyCon
and send some notes.   (Unfortunately I have a conflicting venue I need to
attend so will miss PyCon.)

Thanks,
Justin


On Sun, Feb 10, 2013 at 9:18 AM, Giovanni Bajo <rasky at develer.com> wrote:

> 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
>
>
>
>
>
> _______________________________________________
> Catalog-SIG mailing list
> Catalog-SIG at python.org
> http://mail.python.org/mailman/listinfo/catalog-sig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20130210/eff626a4/attachment-0001.html>