[pacman-dev] pacman signing security vulnerabilities

[Michael Seiwald]

Hello,

sorry for the late answer.

so since we think that some of our points got misunderstood, we would
like to clarify some aspects.

On 02/08/2011 11:02 PM, Dan McGee wrote:
>> (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.
> But not one key, and how does one verify a package they got that was
> not in a sync DB? Or in a sync DB managed by someone they may trust
> less, but packaged by someone they may trust more?

A package not in a sync DB cannot be verified - regardless of keeping
the package signature in the sync db. If the sync DB is signed, the hash
of the package file is sufficient to verify its integrity. The only way
allowing for the verification of packages which are not part of the sync
DB I can think of would be to somehow make the packages contain the
signatures (like RPM packages).

>> 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.
> Sure- but I'm not quite sure why this makes a difference- if just the
> DB is signed, or the DB + packages, the same keys would be viewed as
> valid for both.

If only the DB is signed, the private key could lie encrypted on a
guarded server. So instead of having multiple scattered private keys,
one would suffice.

>> 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.

Our point was:
If an attacker gets hold of any maintainer key, he can modify arbitrary
packages and re-sign them and also the sync db. This does not
necessarily has to be on the main archlinux server but could also be
achieved through Man-In-The-Middle attacks on a syncing mirror. The
mirror could even be hosted by a malicious entity.

> 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.

But only on the main archlinux server. You could not prevent an attacker
from hosting malicious mirrors with correct signatures. GPG key
revocation solves this issue but is not that easy - revocations have to
be downloaded and checked against before every update operation (during
which the keys could be modified or substituted, a backdoor installed etc.).


> 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.

In our opinion having one key on a central, guarded server is better
than having multiple keys scattered on various client machines. The key
could still be protected by a passphrase and only unlocked (manually)
during the signature process.

>> The server would then verify the signature and afterwards automatically
>> sign the updated sync db with the repository key.
>> Another possibility would be to keep the maintainers’ signature in the
>> package (e.g. in the .PKGINFO file)
> It is impossible to sign yourself, so this is not going to work,
> unless I'm missing something. Even with that said, how is a detached
> signature any less secure, whether it be in a standalone file or
> base64 encoded in the sync repository?

Yes, we didn’t think about Arch’s package format when writing this. But
verifying packages which are not in the sync DB would only be possible
with either a detached package signature (then the user would have to
download two files) or a signature that is somehow inside the package
(which would require a change in Arch’s package format). The main
problem is that including the package signatures in the sync db without
pacman differentiating between repo- and maintainer keys makes the whole
thing less secure because there are more keys around which could get
compromised.

What would make the whole process a lot more secure is choosing
specifically the public key of the maintainer of the package (which can
be obtained from the sync DB) when verifying packages.

>> and differentiate between maintainer
>> keys and the repository key when verifying the signatures in pacman
>> (i.e. separate keyrings in /etc/pacman.d/gnupg). Then the package
>> signatures would add additional security because an attacker in
>> possession of the central repository key could not sign the packages
>> themselves. An attacker in possession of any maintainer key could not
>> sign the root metadata (sync db), either.
> This makes a lot of sense- keeping the two sets of keys as independent
> verification would help, although in the case of any private repo, I
> would expect the same signature on both package and DB, so we would
> still want a way to allow for that.

Best regards,

Christoph
Michael