* David Kalnischkies <da...@kalnischkies.de>, 2017-05-28, 10:35:
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
Interesting. I didn't know about this feature.
89901946f936 says "the pinning is in effect as long as the (then old) Release
file is considered valid". If this is accurate, then the attacker could keep
serving stale (but still valid) security.d.o/d/jessie/updates until the release
file expires, then immediately switch to jessie.
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
Awesome.
– but its hard to get right as some changes are legit
Right. Suite or Codename could naturally change, though not both at the same
time.
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).
Is there a warning if Date goes back in time?
--
Jakub Wilk
