Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 539954 - Gentoo latest files are unsigned
Summary: Gentoo latest files are unsigned
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Misc (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Security
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-13 10:45 UTC by Patrick Schleizer
Modified: 2015-02-14 00:04 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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) archtester Gentoo Infrastructure gentoo-dev Security 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 gentoo-dev 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 gentoo-dev 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) archtester Gentoo Infrastructure gentoo-dev Security 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.