On Tue, May 30, 2017 at 01:29:33AM +0200, Jakub Wilk wrote: > * David Kalnischkies <david@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. The repository can use a different key then, so kinda yes. I picked reusing Valid-Until over introducing another Date field for the time being to push a bit for its adoption. Ideally, I would like to introduce a date before Valid-Until with which the repository can declare "next update should be" and if that date passed nagg the user about it. After all, repositories like sid are updated 4 times a day, but valid for 7 days. A lot of security updates can happen in that timeframe… Of course, no-push/local mirrors users will complain so that must be a subtil nagg and easy to extend/disable. We could go with a date for signed-by alone, but then there is the idea of making it easier to limit keys to a specific repository and not having it available for the others (signed-by sources.list option currently, but instead kinda pre-configured) which kinda obsoletes signed-by in the Release file anyhow. > > – 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. That is actually a change a user should confirm as that comes with huge changes (usually if you think jessie->stretch for stable) – and the main reason to check that is actually pinning which tends to work alot with suite/codenames. Then again, that change is less interesting for testing, so I guess a user should have the option of saying: For this repository, I don't care about this change ever. Version is tricky as that 'liberally' changes and the difference between major/minor is like always for versions not well defined. For the moment I accept Version changes with a notice and the others are errors a user must confirm in some way. I do wonder through if its a good idea to have an automatic acceptance after X days as errors always carry the risk of causing the user to be confused and hoping they would disappear on their own – but then that feels icky and is yet another Valid-Until-esk date. > > Practically you have some added complications in the attack as > > 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? No, this is handled as a not-modified-since, so all you see is a 'Hit' in the log and no data is pulled. The reason is simply that in a world of mirror rotations that would generate false-positives too often. So kind of the same reason why Valid-Until period is so long or why a "Best-Used-Before" date isn't implemented yet. Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature