[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files

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.:

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.

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
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
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
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
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.


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply to: