FeatureSpecification: apt-third-party

[Tristan Wibberley]

Carried on from devel.

I've thought of something to avoid the security issue of a fourth party
getting a user to install an insecure package from an existing
repository that they didn't realise they were installing.

Scenario:

Trusted repository has various pieces of software that will solve the
user's problem, and also has a buggy piece of software that the user
isn't interested in. Specifically, the bug manifests as an exploitable flaw.

Fourth party has a web pages describing a solution to the problem and
provides an apt stanza file (format as specified in the wiki:
https://launchpad.net/distros/ubuntu/+spec/apt-third-party) to install
the software that solves this problem. Fourth party includes the
exploitable package.

The user clicks the url, and a GUI appears with various warnings. The
user indicates that he/she trusts the repository and relies on the
packages to be installed as being necessary.

Thus the fourth party can know that somebody has just received the file,
what their IP address is, and that it is likely they have just installed
an exploit known to the fourth party.

Solution:

The file format should include an url to get the canonical form and the
installer should check that the url is within the repository tree. Then
the repository owner can ensure that only certain sets of packages can
be requested in one go, and unrelated packages can't be tacked on
without being noticed. Alternatively a signing method where the
signature is checked with a public key made available at the target
repository

This doesn't help where the *desired* package selection has an exploit,
but in that case the user actually *wants* those packages, so that's
what the user gets.

================================

I also thought of what could become a common problem, that of
unmaintained repositories. A known and trusted developer could have an
old repository lying around on their main website (it is actually quite
likely since developers may come to keep previous releases around in
repository format where they currently keep them around as tarballs and
debs). An attacker could easily exploit that without the user getting a
chance to see that it is an outdated version.

Solution: add a file to the repository format containing an expiry
date/time whereby the user will receive a warning if an attacker has
sent them to an old repository. If the repository admin considers that
it is maintained well, he/she updates the expiry file.

-- 
Tristan Wibberley