[pacman-dev] pacman signing security vulnerabilities

[Dan McGee]

On Tue, Feb 8, 2011 at 5:43 PM, Denis A. Altoé Falqueto
<denisfalqueto at gmail.com> wrote:
> On Tue, Feb 8, 2011 at 8:02 PM, Dan McGee <dpmcgee at gmail.com> wrote:
>> On Tue, Feb 8, 2011 at 2:47 PM, Michael Seiwald <michael at mseiwald.at> wrote:
>>> (3) Repository Freeze Attacks
>>> An attacker is able to prevent clients from updating by replaying an old
>>> sync db file with a valid signature. This could be used to keep clients
>>> from updating software with known vulnerabilities.
>>> Solution: gpg-signatures already contain a timestamp. Before each
>>> update, pacman could check if the timestamp is not older than a
>>> specified period (e.g. a week).
>>
>> Yes, very well known, and the site I tell all people to have a read
>> before hacking on this stuff:
>> http://www.cs.arizona.edu/stork/packagemanagersecurity/
>>
>> We will find a way to address this before we consider package signing complete.
>
> I remember some talking about that in the mailing list. It was
> suggested to have a time limit for the validity of the database
> signature, so the developers would have to generate a new signature at
> least every n days, if the database didn't change. That would be a
> worst case scenario, because the rolling release nature of Arch
> generates lots of database updates and they would be signed very
> often.

Allan and I are going to repeat this until our heads explode, but
pacman != Arch Linux.

What was that?

pacman != Arch Linux.

This needs to somehow be feasible for *everyone*, or at least not get
in their way. I've had (although it has gone stagnant) my one-package
eee kernel repo; I shouldn't have to sign that every 10 days if
nothing changes, nor should some in-office repo providing a custom 10
packages or so, esp. if said database can be fetched from a reliable
(HTTPS with valid cert, say) source.

>>> (4) Signing keys
>>> Currently when adding a signed package to the repository with repo-add,
>>> the signature of the package itself (generated with the package
>>> maintainers’ key) is included into the sync db (as %PGPSIG% field in the
>>> desc file of the package). Afterwards, the updated sync db is also
>>> signed. Firstly, we are not sure how this should be handled in practice.
>>> Will the sync db be signed with a central repository key? Or with one of
>>> the developers’ keys? Either way, the package signature in the sync db
>>> (%PGPSIG%) adds no additional security value, because when pacman
>>> verifies both the package signature and the signature of the sync db, it
>>> uses one single keyring (/etc/pacman.d/gnupg/pupring.gpg) for all the
>>> signatures.
>>> If an attacker can acquire a private key of any maintainer
>>> he can generate valid signatures for every package and also for the sync
>>> db. The more maintainers there are, the more private keys are around and
>>> the bigger is the risk of a key being compromised.
>>> Suggestions: there are different ways to improve the situation. One
>>> possibility would be to remove the package signatures from the the sync
>>> db and only sign the sync db itself with a central repository key on the
>>> server. This is the way Debian does it. Of course this requires some
>>> kind of system where the maintainers can submit their (signed) packages.
>> So now you've opened up another can of worms, from what I see. If the
>> database key was compromised, every package also has to be viewed as
>> compromised or possibly tampered with. If 100 packages are signed with
>> ~15 different keys, even if whatever key last signed the repository is
>> compromised, we don't have to reverify any existing packages except
>> those signed with the compromised key.
>>
>> So yes, there is the possibility of someone trying to resign every
>> package, but that could be seemingly prevented or at least guarded
>> against with smart backups and snapshots.
>>
>> No matter what, private keys should not be ending up on a central
>> server (outside of maybe a repo-signing key)- that is too dangerous as
>> you point out.
>
> Yes, that is really a problem. I agree that we should avoid putting
> private keys on any server. We should base the solution on the concept
> of web of trust, so that would not depend on any implementation in
> Pacman. I mean, Pacman just trust the response given by gpg, that
> will, in its turn, be based on the trust level and relationship of
> keys defined by the final user (remember, we assume the users know
> what they are doing and are the only ones responsible for their
> system).
>
> I'm trying to devise an algorithm that could have the following properties:
>
> * must be run in the machine of the developer, so the private key
> doesn't need to be kept in other places;
> * must sign the packages that are stored in the server, to avoid
> unnecessary file transfers
At least in the "standard" development and packaging scenario, these
first two things are happening on the developer's machine. I don't see
too many cases where a developer should use a specific signing key on
more than one machine; that way if some build machine key gets
compromised it can be revoked without having to revoke all keys. If I
am remembering GPG right.

> * be not very different of repo-add, so the developers doesn't feel
> demotivated to acquire a new habit
Either people use it or don't, but enforcement comes via policy on
this one- obviously our main repos will always have it, but I agree
making it easy enough for everyone to want to use it is also a good
thing.

> If someone have some suggestions, please feel free to talk.
>