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

On Wed, 2014-10-29 at 19:39 -0700, Russ Allbery wrote: 
> Packages appearing on mirrors is not how we notify Debian users of
> security updates.  We do that by issuing a security advisory.
Aha,... well... sounds like nitpicking,... I guess the least of the
users have subscribed the respective mailing list or look regularly at

And apart from that:
with respect to mail:
- the mails seem to often lag behind the actual release of a fix, so
there is the same problem that users may not be notified as fast as they
could be
- while mails can be secured, there is no guarantee at all that mails
arrive the subscribers

with respect to web:
- that uses GANDI CA certs, so this is not really a secure way to be
informed about that either.

> Yes, it's
> nice to protect against archive downgrade attacks, but validity periods
> are not our primary defense against that.  Our primary defense is that we
> send out a DSA telling people exactly what package versions they need.  If
> those package versions aren't available, that should raise red flags.
See above, both means of distributing DSAs seem not to protect against
downgard/blocking attacks.

> Teams that run Debian servers in production should be checking that all
> packages on their hosts are upgraded to the necessary versions.
Even apart from the above problems, I doubt that mail is the appropriate
mean for many admins to get notified about security upgrades.
People may deploy security upgrades automated or at least check for them
via Nagios and friends, rather than reading mails, which they get for
*all* DSAs and not just the packages they actually use.

To be honest, it's really awkward to see how much all this is apparently
fought against.
In many cases, our security teams (and all the other security teams) do
such a wonderful job,... make great efforts to synchronise the
deployment of upgrades between distros when they're reported secretly to
the right channels, and then in a concentrated effort, all the different
organisations try to release upgrades and information, so that people
can update before attackers found out what the hole is and start
exploiting it.
And it's already reality that MitM is not only possible to governments
or network operators... we see highly sophisticated attacks of criminals
directly targeting single persons over multiple paths (like e.g. when
smsTAN and the repsective computer is attacked).
So one should generally assume that Mallory sits around, waiting.

> I've run such production system clusters for many years now, and the
> machinery and tools that you need to have in place to ensure that you
> actually pushed out the security update to all systems will also trivially
> catch downgrade attacks of the type that you're describing.
I really wonder how you can do that with the above means.

> But we shouldn't confuse that with the
> right way to check for security updates for Debian systems.  People who
> care about security updates need to be subscribed to
> debian-security-announce and reading the DSAs.
Well, for the reasons laid out above, I disagree that this is a safe
mean. Any attacker that is able to do a downgrade attack is likely also
able to block your mails, ideally only such mail of packages that you
run, so you'll even continue to get some DSAs, just not the ones that
apply to you.

> > 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.
> But the MITM attacker who is launching a downgrade attack can't do this.
Sure... I wasn't talking about Mallory here... I referred to whether
placing the validity check mainly in the client (instead of the server)
would help anything against a rogue (signing) server, which it of course
does not.

> It seems to me that if you want to lower the chances of a downgrade attack
> for your systems, setting the validity period on your systems is exactly
> the tool that you need.  There's no need for anything to change on the
> server side for you to get that protection.
Well I don't think it would work, would it?
The Release file contains e.g.:
Date: Thu, 30 Oct 2014 02:54:04 UTC 
Valid-Until: Thu, 06 Nov 2014 02:54:04 UTC

When I now lower the validity to something very small, e.g. 4 hours,
than beginning with 30 Oct 2014 06:54:04 UTC everything will fail for me
unless a resigning mechanism was in place like such that was discussed
in #752450.

So AFAIU, on can only enlarge the validity.

Apart from that, there is no need that other people shouldn't benefit.


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

Reply to: