Bug 539954 – Gentoo latest files are unsigned

• Product: Gentoo Security
• Status: RESOLVED WONTFIX

[Description Patrick Schleizer 2015-02-13 10:45:27 UTC]

* file in question: http://distfiles.gentoo.org/releases/amd64/autobuilds/latest-stage3-amd64-hardened.txt (http://www.webcitation.org/6VY9gFGrq)
* folder: http://distfiles.gentoo.org/releases/amd64/autobuilds/ (http://www.webcitation.org/6VY9hYhkc)

This is problematic, because automated build scripts cannot verify this file. An adversary could use this to mount rollback [1] (downgrade) or indefinite freeze [2] attacks.

I suggest to sign such files, to have an expiration date for those signatures (to prevent downgrade and indefinite freeze attacks), and to have an automated, scheduled recreation of such signatures with new expriation dates.

References:
[1] [2] Defined as per TUF (The Update Framework) - Attacks and
Weaknesses - Threat Model:
https://github.com/theupdateframework/tuf/blob/develop/SECURITY.md
http://www.webcitation.org/6F7Io2ncN


Reproducible: Always

[Comment 1 Alex Legler (RETIRED) 2015-02-13 11:16:23 UTC]

I don't see the threat nor the gain from implementing your suggestion.

Stages are a mere stepping stone to a system, we have never made the promise that what you get there is up to date. Before autobuilds, stages were up to a year old. Now with 'weekly' stages (in quotes as the process does fail at times giving you maybe two stages a month), that lack of a promise hasn't changed.
You always need to update (a) your tree and (b) your packages to have an up-to-date system.

The threat model you quote is from a (single) piece of software that is constantly updated, that just doesn't apply to stages.

Expiring signatures sounds like something that incurs a lot of infra/releng work for little to no gain.
Besides, if the mirror fiddles with the latest- files, I think we have a few other things we'd need to worry about.

So: --sync && -vauDN world && glsa-check || die

[Comment 2 Sebastian Pipping 2015-02-13 22:36:22 UTC]

> Besides, if the mirror fiddles with the latest- files, I think we have a few
> other things we'd need to worry about.

What would it be?


If we do sign stage3 and portage snapshot tarballs: what is keeping us from signing the latest file, too?

[Comment 3 Sebastian Pipping 2015-02-13 23:04:32 UTC]

> I don't see the threat

The threat is that a mirror could trick software using mirror files and relying on that latest file into using old software, e.g. a backup of a stage3 from two years ago with known vulnerability X in software Y.

[Comment 4 Alex Legler (RETIRED) 2015-02-14 00:04:59 UTC]

(In reply to Sebastian Pipping from comment #2)
> If we do sign stage3 and portage snapshot tarballs: what is keeping us from
> signing the latest file, too?

The fact that you gain little to nothing.

(In reply to Sebastian Pipping from comment #3)
> > I don't see the threat
> 
> The threat is that a mirror could trick software using mirror files and
> relying on that latest file into using old software, e.g. a backup of a
> stage3 from two years ago with known vulnerability X in software Y.

See c#1 on why that is not a problem.