On Thu, May 25, 2017 at 02:10:11PM +0200, Julian Andres Klode wrote: > On Thu, May 25, 2017 at 01:30:13PM +0200, Jakub Wilk wrote: > > Unfortunately, this protection is ineffective. All the attacker needs to do > > to hide security updates is to replace all the files from > > http://security.debian.org/dists/$DIST/updates/ with the ones from > > http://deb.debian.org/debian/dists/$DIST/ . > > That's easily fixable by enabling key pinning for the security repository, see > https://wiki.debian.org/DebianRepository/Format?action=show&redirect=RepositoryFormat#Signed-By > (and sources.list(5)). > > Note that you have to pin both the master and the subkeys (actually > only the latter), as APT only checks the concrete key fingerprints > (at some point it might check the master key too). Beside doing this as a repository owner, you can also do this as a "normal" user with an option of the same name in your sources.list. > If you want a more generic thing, you could add some kind of UUID to > Release files that must not change for a given repository. But that's > really just less safe than using key pinning. I am working on having apt error out/asking for explicit confirmation if a repository changes metadata information like suite/codename (or label/origin which is more related here) which should help a bit here, too – but its hard to get right as some changes are legit and getting such changes noticed and confirmable in all frontends without breaking ABI entirely… Practically you have some added complications in the attack as Release files need to go forward in time, so if your user happened to have updated its security data before the Date is likely newer than that of any stable release you can use (that isn't the case for < 1.0 which you were testing, but for >= 1.1). Best regards David Kalnischkies P.S.: "Securing" the transport via HTTPS or Tor isn't really a solution btw as this isn't a "conventional" replay attack as you aren't replaying data you had seen before, but (unrelated) data which passes as valid. You can do that just fine if you don't work on the transport level, e.g. if you are in control of a mirror (or a Tor exit node and/or service). Also, there is a bug basically every week in any HTTPS stack you can think of, so it is hardly the solution to every problem. You can sell it as an added hurdled perhaps, but not as the solution – and due to bugs it might become easier to exploit other things, so its a trade off. Beside that stomping your boots on the ground declaring "Debian must do X" has no effect – but if everyone stomping would instead actually contribute to make X viable… doesn't happen of course. P.P.S.: Instead of following random advice from random people in random bugreports on the internet regarding which onion services you might want to use, you can also look in the README of the apt-transport-tor package which lists a few, can be updated if need be and is far more resistent to modification from evil actors (Disclaimer: I am the maintainer and the README discourages using it as the *only* source). Also, the source should read "tor+http://sha1.onion"; as http alone will generate an error.
Attachment:
signature.asc
Description: PGP signature