[pacman-dev] pacman signing security vulnerabilities

[Michael Seiwald]

Hello there!

We are two students from Austria and have evaluated the ‘gpg’ branch of
pacman by Allan, among other package managers, in the course of a
project on secure package management. We have found a few points that
could be seen as security problems so we thought we’d let you know about
them.

(1) Unlimited size of signature/sync db
If pacman is confronted with signature or sync db files with unlimited
size, it just keeps downloading them until the partition containing
/var/lib/pacman is filled up. This could be exploited in
Denial-of-Service-Attacks, e.g. preventing the writing of log data or mails.
Solution: Limit the maximum size of the sync db and signature files to a
specified value (e.g. 20MB) when downloading them.

(2) Packages with unlimited size
This scenario is similar to the above, but this time the size of the
packages is known from the sync db.
Solution: only download packages up to the size specified in the sync
db; abort the download afterwards.

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

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

We are happy to see that Archlinux finally gets package signatures and
hope that with our suggestions we can contribute to improving the
security of the architecture before the new system is actually rolled out.

Best regards,

Christoph
Michael