The TUF specification defines a standard for delivering software updates securely and deals with some attacks that APT is still vulnerable to, at least in the default configuration. While it is possible to configure APT repositories with advanced security like OpenPGP encryption, offline signing keys and time-limited snapshots, those configurations are not the default and vary a lot across third party repositories. An effort was made to document best practices with regards to such repositories in DebianRepository/UseThirdParty but lots of work still needs to be done, which document aims to cover.

Threat model

We assume an attacker can compromise a mirror either as a MITM on the HTTP connexion, or simply by compromising the host itself. We also assume that official Debian repositories can be compromised in the same way and wish to find ways to limit the damage such a compromise could do to the trust chain of existing installs.

UntrustedDebs is out of scope here: it is assumed that the content of .deb files is trusted or somehow sanitized or controlled.

Known issues

SecureApt has some known limitations, in particular in the default configuration, which were outlined in a talk at Debconf 17. Some of those claims were partially debunked by Julian Andres Klode, a member of the APT development team.

This goes over issues that TUF claims to fix and reviews how APT might be vulnerable to them and some of the mitigation strategies it takes to workaround those issues. In a later section we propose further modifications to the APT client that would definitely fix those issues.

Indefinite freeze and replay attacks

Even with SecureApt a repository is vulnerable to replay attacks a fresh Debian install from an old install image could fail to update to a newer version if it only relies on the stable repositories. The security-master repositories work around that issue by including a Valid-Until field that thwarts replay attacks, with a 10-day expiration date on Release files. Unfortunately, this is not the default and it is not included in the stable Release files either.

Repository impersonation

A commonly used method to trust a third-party repository is to use the apt-key command in a variation of this:

curl http://example.com/openpgp.key | apt-key add -

This imports the key in the global trust anchors and allows the third-party repository to masquerade as an official Debian repository, making any sort of pinning or restriction on the repository ineffective.

Key rotation issues

A key compromise on APT repositories is catastrophic: keys need to be revoked and the whole trust path need to be reset.

Completed work

SecureApt already accomplishes a lot of what TUF requires, as juliank explained. Specifically, here is what has changed in newer release to fix some security issues.

Mandatory signed repositories

Unsigned repositories are vulnerable to many security issues: any package can be replaced by a hostile mirror or MITM attack if the trust chain starting with the Release file isn't complete. APT clients SHOULD NOT accept unsigned Release files and force repositories to be authenticated. This is the default in APT 1.1 (Debian stretch) and later where AllowInsecureRepositories defaults to false.

We might consider making it impossible to use unsigned repositories at all, provided that the tools are there to more easily generate signed repositories.

Endless stream protection

APT clients already read a fixed size for the Release file and are not vulnerable to the "endless stream" attack described by TUF.

Work in progress

Those are things that are currently being worked on to improve APT's resilience to the above attacks.

Trusted keys distribution

Bug #861695 proposes moving more keys out of the global scope and defaulting keys to be restricted using signed-by fields. It has been postponed to after the stretch release and should be reactived.

Key revocation improvements

In August 2017, Julian proposed an out of band mechanism for key revocation.

Future work

Those are ideas that should be implemented in apt to improve the security properties of the system.

Mandatory repository scoping

signed-by fields should be mandatory, to force keys to be specified uniquely for each repository. This is to keep keep third-party keys from signing official repositories and limit possible breaches of a repository key to a single repository.

Mandatory signature expiration

To thwart replay and freeze attacks, TUF proposes a timestamp key that is rotated every time the repository is updated. The equivalent of this in SecureApt is the Release file, with a Valid-Until field. This should be enforced by apt clients and deployed in all APT repositories.

Offline signing keys

TUF strongly recommend trust anchors to be stored offline. While it is possible to do this in SecureApt by using subkeys, it is not enforced anywhere and has only recently (since stretch) been adopted in official repositories.

This should be the default in third party repositories and a warning should be issued by APT clients when a remote repository does not use a subkey for signing the Release file. While a subkey is no garantee of offline key usage, we do not have a better way of enforcing this and the contrary (no subkey) certainly garantees the signing key is online, which we want to avoid.

Key rotation

To ensure regular key rotation, expiration dates on signature keys should be enforced by APT clients. A standard way to distribute new keys must be clarified: right now the official Debian archives operate through the debian-archive-keyring package, but this is not standardized and the tools to create those packages are not obvious to new operators. As far as I can tell, the procedure for such key rotations is completely manual at this stage and could benefit from some level of automation, by regularly rotating the signing key on some repositories. Right now the stretch and security signing keys have the same expiration date as the certification key and expire in 2025, 8 years after creation.

Other ideas

Those are not features part of APT itself, but improvements that could be done in other tools.

Repository health check tool

We could make a tool that scans your local system's apt configurations, identifies improvments that you could either (a) make locally, or (b) ask the repository owner to make, or (c) both. Ideally, the APT client itself would implement such controls, as detailed above but an intermediate step might be to write a linting tool first.

Automated repository creation

Right now, there is a multitude of tools (e.g. DebianRepository/Setup) to manage repositories and they only manage a subset of the above functionality. Repository management tools like reprepro should implement (or at lesat document) extra steps required to have a properly secured repository as asserted by the APT maintainers.

This includes OpenPGP key generation, including offline certification keys, repository-archive-keyring Debian packaging (to allow for key rotation) and proper user instructions. Right now, there are too many moving parts in creating a Debian APT repository to hope that *anyone* will do it correctly and securely.

Credits

This document was original written by TheAnarcat after reviewing the TUF specification.

See also

Comments

Comments are welcome here.