apt-zeroconf team mailing list archive

[Neil Shepperd <nshepperd@xxxxxxxxx>]

Hi list,

I think I've pretty much mapped out the whole security situation here,
protecting against both "honest" buggy proxies and malicious ones.
Basically we have the md5/sha1/sha256 and the package's size to
authenticate it. The checksums are mostly needed to prevent deliberate
attacks, while the size will probably be enough to prevent e.g.
unofficial versions of packages being used instead.

So if we have hosts A, B, C, and D...
A: client
B: good server
C: buggy/unoffical packages server
D: evil server

APT connecting to the AZC instance on A wants to download some package.

Three situations:

1 ---- The APT client is on A itself (ie. connecting to localhost)
A knows: the url, and can get the checksum and size from apt-cache
    * hosts B C D provide the sizes of their packages
    * this eliminates C which is different (it has a same-named package)
    * we try to download from D --> calculate checksum --> its different
    * so download from B --> calculate checksum --> it matches
    * so we send that package to apt

2 ---- the APT client is on some other server E and connecting to A
A knows: the url only
    * we can look for the url in apt-cache
and /usr/share/update-manager/mirrors.cfg
    * if we find it, we have the url, checksum and size
    * so we can do the same as in 1 easily
    * if not, we can HEAD the url and get the package's size
    * if we have the package locally, we trust ourselves, so the size is
enough to verify that package, and we can send the local package
    * but if we don't, we don't have a checksum, so we can't download
from other (possibly untrusted) peers
    * so we'll download the full package from the url

3 ---- the APT client is on some other server E
Rather than installing avahi and apt-zeroconf on E, we install some sort
of 50-line miniproxy instead, with the IP of A set in its configuration.
This proxy send accesses A normally, but with POST or GET data
containing the checksum and size obtained by querying apt-cache
So, assuming A is trustworthy (it *is* set in system configuration), it
has all information it needs to proceed the same as in situation 1.


As far as I can see, this method is pretty much completely secure.
Please discuss if you think I've forgotten anything...

Neil