[pacman-dev] pacman signing security vulnerabilities

[Denis A. Altoé Falqueto]

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:
>> 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.
>
> Awesome! Thanks for looking at this stuff. I know our primary efforts
> haven't been focused on this in a while but it has to be tackled as
> our next big project.

I second those words. New blood is always good to renew the motivation :)

I would like to know if you have also read the wiki page about the
policy of handling the signature process. The link is
https://wiki.archlinux.org/index.php/Package_Signing_Proposal_for_Pacman.
If you didn't know about it, please feel free to suggest any
modifications.

>> (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.
>
> Both interesting. The second one makes quite a bit of sense (Dave, you
> listening?). The first is interesting. Yes, an avenue for DOS, but so
> is pinging your webserver with tons of requests or any of a multitude
> of other things that would cause continuous writes. 20 MB seems
> potentially low for example, if you are using sync databases
> containing files entries or something (community has a ~4.5 MB
> database, conceivably someone could have one larger without being
> malicious). Most of all I just don't want a hardcoded limit that would
> ever be restrictive, so I don't know what the answer is here.
>
> tl;dr We have a potential problem but I'm not sure of its true severity.

Maybe we could choose a limit just to avoid the fact of having none.
For example, 200 MB for database and 2 MB for signatures. That should
be enough for the foreseeable future. If needed, a change would be
very straightforward.

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

>> (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
* be not very different of repo-add, so the developers doesn't feel
demotivated to acquire a new habit

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

>> 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, it is not possible because a package is only a compacted .tar
file for the final content of the package. Debian and RPM, for the
other way, already have internal sub-archives that separate the real
content from the signatures. We don't have that and, as far as I know,
are not going to change the format of the 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.

Yes, but we would have to make a little more effort for the people
that own the keys for database signing. That should be kept in mind
when devising the solution. And the implementation should be kept
external to pacman itself (it should rely solely on gpg and the web of
trust, if possible).

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

Again, thanks for taking the time to discuss that with us.

-- 
A: Because it obfuscates the reading.
Q: Why is top posting so bad?

-------------------------------------------
Denis A. Altoe Falqueto
Linux user #524555
-------------------------------------------