FeatureSpecification: apt-third-party

[Jerry Haltom]

I think you forgot to send this to the ubuntu-devel mailing list. Mind
doing so?



My reply:

I don't really have any idea what you're trying to solve. Anything we do
is circumventable, as the Entire Point is to add Untrusted Repositories.
Doesn't matter if it's old or out of date or what.

This tool isn't for installing Ubuntu software. It's for installing
non-Ubuntu software.

It just happens to have a secondary use of installing Ubuntu software...
which by the way is already pretty well covered, gnome-app-install,
synaptic,


On Thu, 2006-04-06 at 20:25 +0100, Tristan Wibberley wrote:
> 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.
>