Pacman

Welcome to the Pacman bug tracker. Please search the current bugs and feature requests before filing a new one! Use advanced search and select "Search in Comments".

* Please select the correct category and version.
* Write a descriptive summary, background info, and provide a reproducible test case whenever possible.
Tasklist

FS#67232 - verify package checksum integrity with signatures downloaded remotely

Attached to Project: Pacman
Opened by Eli Schwartz (eschwartz) - Thursday, 09 July 2020, 03:50 GMT
Last edited by Eli Schwartz (eschwartz) - Thursday, 09 July 2020, 03:51 GMT
Task Type Bug Report
Category Backend/Core
Status Unassigned
Assigned To Anatol Pomozov (anatolik)
Architecture All
Severity High
Priority Normal
Reported Version git
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

In https://git.archlinux.org/pacman.git/commit/?id=f3dfba73d22b7eca3810a8114f2aab63da488b4c we fixed  FS#33992  by ensuring signatures are always downloaded after the package is downloaded.

This means if a database doesn't have embedded signatures, but our siglevel wants the package to be signed, we can still validate that signature.

However, this breaks our previous checksumming logic, i.e. we don't checksum files if we're checking their PGP signature, because the checksum and the PGP signature both come from the database and either one will only match a byte-identical file.
Now that signatures don't necessarily come from the database, we cannot guarantee that anymore -- the package file could be lots of different things, as long as it's signed by *a* valid key, somehow.

The fix is to check if we're using an embedded or detached signature, and in the latter case, also check the package checksums.

This task depends upon

Comment by Allan McRae (Allan) - Thursday, 09 July 2020, 05:31 GMT
After discussion on IRC, I don't think this attack vector exists if repo databases are signed. We confirm package name and versions match what is in the repo before signing them.
Comment by Eli Schwartz (eschwartz) - Thursday, 09 July 2020, 14:19 GMT
Just depending on the name and version isn't good enough. It weakens security in a way I don't feel is justified. If at any time an attacker can get a validly signed pkgname-fullver, they can silently replace packages without modifying the db.

- Evil maid attacks might temporarily get access to a trusted PGP key, but not access to the upload server. Bulk-sign bad packages, then attack user mirrors. Optionally, bulk-sign packages matching predicted future package versions to continue attacking after rebuilds/updates

- A trusted mirror might provide only databases but not packages with pacman doing failover to the second mirror, or a distribution might directly serve databases but load balance packages across a mirror network. Rogue packagers in control of a mirror can perform targeted attacks against specific users without leaving audit traces on the master repository server.

- Packages built and signed by third parties added to pacman.conf but ranked below distro repos can arbitrarily sign and replace core packages, while the user expected they only need to vet and possibly sandbox packages being installed from [otherrepo] (e.g. eyeballing the output of VerbosePkgLists, installing with pacman --noscriptlet, pacinstall --no-hooks --no-scriptlet). They can also perform targeted attacks in the load-balanced case. (This can be solved by per-repo pinning of valid key fingerprints.)

- Packagers might upload testing packages and ask users to install them with pacman -U, then after it turns out to be broken, rebuild without bumping pkgrel and ask users to install once again with pacman -U, then directly move the second attempt to the official repos. Attackers can now feed people broken packages that crash the system.
Comment by Eli Schwartz (eschwartz) - Thursday, 09 July 2020, 14:26 GMT
One possible enhancement of pacman would be allowing keys that are only trusted to sign the database, and/or the only key trusted to sign the database. This would be really nice to have in order to reduce the risk of storing dedicated private keys on a signing server, and prevent attackers with access to a package-signing key from replacing packages after the fact.

But that wouldn't help, if an attacker with access to a package-signing key could replace packages (permitted by the proposed key policy) and doesn't *need* to rebuild the database and re-sign it (not permitted by the proposed key policy without a db-signing key).
Comment by Anatol Pomozov (anatolik) - Tuesday, 28 July 2020, 05:55 GMT
I agree with Eli that if we want to verify package integrity then a cryptographically strong hash value of the file content should be used. If a single bit of the package has changed it will affect the hash value.

pacman database already contains SHA256 for packages. We just need to enable it for detached signatures use-case.

Loading...