GNU bug report logs - #19479
Package manager vulnerable

Previous Next

Full log

View this message in rfc822 format

From: Stefan Kangas <stefan <at> marxist.se>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 19479 <at> debbugs.gnu.org, Noam Postavsky <npostavs <at> gmail.com>
Subject: bug#19479: Package manager vulnerable to replay attacks
Date: Wed, 25 Nov 2020 22:02:32 -0500

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> While not perfect, with a secure hash function, collisions are hard
>> enough to find that we for our purposes (like the rest of the world) can
>> happily not worry about it.  In comparison, it is immeasurably easier to
>> fake a version number than having to defeat a hash function.  I think
>> this is a significant drawback of what you propose.
>
> I'm not sure what you mean by it being easier: since the tarballs are
> cryptographically signed, just like `archive-contents`, if
> `archive-contents` points to `foo-42.1.tar` and that tarball has
> a correct signature and its content says that it is indeed the package
> `foo-42.1`, then I'm not sure which easy attack would be applicable.

I guess it's in the nature of attacks that we generally don't know or
think about them in advance.  This is precisely why, when it comes to
security, it IMO a good idea to use battle-tested and generally accepted
solutions.

> AFAICT you'd have to find some old signed tarball which we accidentally
> built with an incorrect content?  But presumably if we ever mess up
> a tarball like that (which is indeed possible), we'd then want to be
> careful not to "reuse" that version number, no?

I'm not sure we can assume that we would always detect when we mess up.
But yes, this sounds like one possible attack vector.

> I think it's comparable: the main failings wold require some error on
> our side in how we build and sign packages, and in most such cases
> I think we'd end up with holes with either scheme.

Agreed, we could make mistakes in implementing either scheme.

FWIW, I think that with the version number idea, there are more places
where we could make important mistakes, since more code would be
involved.  There are also more assumptions that we need to ensure hold
true under all circumstances.  (But see below.)

>> But we could of course also check that the version number is correct.
>> That sounds like a useful sanity check to do.
>
> Exactly.

How about adding this check in addition to the checksum check?  Having
two separate checks together should surely bring more confidence than
either of them would separately.  That sounds like good "defense in
depth" thinking to me.

> I think we'd want to keep the signatures anyway, e.g. they can still be
> checked manually for old tarballs which aren't listed in
> `archive-contents` any more.  And more generally they allow
> authenticating the origin of a package without having to look it up in
> `archive-contents`.

Valid points.  Let's keep them indefinitely.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.