Hey Henrique, et al. I've had lost my interest a bit, since it feels like fighting windmills... but one month has passed and it's perhaps a good time to revisit this.
On Mon, 2014-09-29 at 08:08 -0300, Henrique de Moraes Holschuh wrote: > On Mon, 29 Sep 2014, Christoph Anton Mitterer wrote: > > Now to deal with your concern of larger outages: > > 2) Just because there are no valid [In]Release* files, it doesn't mean > > that those mirrors and their repositories can't be used any longer. The > > data is still there as it was before. > > An application like apt/aptitude/etc. could simply give the user an > > error, telling that the files have expired for hh:mm and could give the > > user and option to nevertheless trust them. > > And the same options could be provided for batch modes. > This is not making any sense anymore. Step back and think about your threat > model in the first place. I do not quite understand what you meant... the attack model ist clear, the technical questions (i.e. distribution to mirrors) as well, and I gave several ways to work around such issues: - there's the way of resigning the Release files and mirroring them with priority, which should work fast enough - adding functionality to the clients to adequately warn about what's happening and allowing them to override the expiration. > The *entire* threat model, not whatever small > part of it that looks easily fixable by a severe reduction to the inrelease > validity period Well I guess you should perhaps look at e.g.: https://www.drupal.org/PSA-2014-003 People had roughly 7 hours (estimated) before that hole was exploited massively all over the net. As far as I understand the security team uploaded a fixed version (of stable) at Wed, 15 Oct 2014 11:43:08 -0500 ... can we see from some logs when this became really available on the mirrors? Anyway this should demonstrate quite practical, how fast attackers are these days and that severely reducing the validity times doesn't just help against some completely unreal attack vectors. Even if the security team is as fast as above, then a victim may be compromised by a downgrade attack, thus not even being notified about new upgrades. > (which you have already been told by several Debian archive > ops _and_ mirror ops people to be very much a Bad Idea). > Now, if you want us to add per-repository validity overrides to source.lists > that can *reduce* the range APT will accept, so that the local admin can > tighten things, that's fine. Well we have that anyway, don't we? But it's probably nothing which is used by the typical majority. Conceptually, the "trust" lies in the server. Even when the client reduces his validity times, than a server could still simply distribute old packages, just newly signed. So the right place for reducing the validity is on the server / repo-meta-data side, not on the client side. If the client side (i.e. apt, aptitude) set their own maximum validity times, than this should rather server to either override the servers or to identify accidentally misconfigured servers which give out e.g. files that have a validity of years or so. > If you're going to propose some sort of tiered > system and a way for apt to actually know it is OK to use this "updates not > often at all" fallback mirror as long as it also has a mirror from the > "fresh stuff only" tier, that would be at least sensible... Would those > help? I don't know, that's what the full threat model analysis is for. Hmm I'd rather say that this sounds like an overly complex solution that is error prone. An in principle it doesn't help, because in that case an MitM-capable attacker would simply block the fresh server,... if the clients then fall back to the fallback mirror in silence, things are useless again. > So, can we get now some alternative proposals that address the fact that > some mirrors need >48H validity, and many leaf mirrors really want at least > a week? Or to help apt detect it is using a mirror that is more outdated > than expected, which *is* the reason 99,999% of our users ever suffer an > "unintended downgrade attack" ? I don't think that there is a way around it, because the whole issue is about the requirement to have up-to-date repository information. From a security point of view, a mirror model in which mirrors are lagging that long behind is simply not adequate. One can have such slow mirrors for repos which don't change often (stable, oldtable, etc.) but for anything which is used to deal security updates to the users (security.d.o, unstable)... slow mirrors are simply broken from a security POV. On Mon, 2014-09-29 at 09:05 -0300, Henrique de Moraes Holschuh wrote: > Sure, 48H or 24H refresh requirements for anything that is mirroring s.d.o > is a restriction we could deploy. Well I guess the drupal example shows that even ranges in about 1 hour would be appropriate. > But there's the DoS concern if there is a > problem refreshing s.d.o from ftp-master. At least, s.d.o. is a lot more > controllable than the normal mirror network. I think the DoS concern is solved by giving the clients appropriate means of interaction and override. If e.g. aptitude sees an outdated Release file, it should tell the user for how long it has been expired, inform him about the potential security issues and then give him the choice to accept it nevertheless. That allows a security conscious admin to check from other places, whether s.d.o is really down, or to look at security announcement lists,... or in extreme cases, to shut down his services (e.g. drupal), wait until he get's a valid Release file when s.d.o is back and only restart the services if everything is fine. > Maybe we could get away with flooding the normal mirror network with a > delayed dump of s.d.o, so that you get fresh data from s.d.o, and it also > gets mirrored to the normal mirrors "soon" so that they can be used as > fallbacks? This solution is s.d.o. specific, but might be worth thinking > about. Mhhh... my main concern is actually rather a suite like unstable. For stable/oldstable I would understand it as follows: The repos rarely change and if they do, than less for security reasons but rather to get a new point-release in. Security updates are dealt via s.d.o. s.d.o: There aren't that much changes anyway, are there? If we considerably shorten the validity of Release files, than we'd simply need to resign them often enough. And s.d.o mirrors would have to pull in these new Release files in due time. If something really changes in the contents of s.d.o, well than this needs to be distributed (along with new Packages and Sources files), but this is nothing different from now. What could happen is, that distribution of Packages and Sources files is so slow, that a mirror has a Release file which doesn't match the Packages/Sources files... i.e. the Release file is already for newer Packages/sources files. I'd dare to say that such slow servers are generally not adequate to be a official Debian mirror, and at least not adequate to be a mirror for s.d.o. What else could happen? Well it could happen, that a slow mirror actually has a current Release file and even current Packages/Sources files,... but it's either to slow with deleting old or fetching new .deb files. Old .deb files (which are not yet deleted, and possibly already exploited again) are not our problem, since the new Release file and its short validity takes care of that. Missing new .deb files will lead to an error on downloading them... but I think that's exactly what we want here: a new version is available, probably fixing the worst security hole ever, the user at least notices that something is wrong and he cannot download a security update. Long story short: slow mirrors are not adequate for being a s.d.o mirror. And I wouldn't expect fast mirrors + push synchronisation to have much problems with very short validity times... or do I miss something here? For testing: Well it depends: Is it often the case that a security fix goes directly into testing? Or are all fixes really distributed via s.d.o first? For unstable: Here's IMO the bigger problem: The situation is in principle the same as above with s.d.o. but since unstable changes basically always, one needs to make sure that the Release file matches the Packages/Sources files (and other similar metadata). I'd guess the problem isn't that much different from what we already have now. The only difference is probably: if we do fast resigning of the Release files (to extend the validity) then we probably do this e.g. 30 mins before it would expire... or maybe one hour before. Mirrors should then of course not yet replace their old Release files when they haven't pulled the new Packages/Sources files (if any) while the old Release files would still be valid. Anyway,... is actually anything going to happen in that question, or are we just discussing for nothing. Right now it doesn't look as if this would actually lead to an end so I'm kinda tempted to close the bug wontfix. Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
