Gentoo Mitigations?

Posted Mar 24, 2011 12:28 UTC (Thu) by alex (subscriber, #1355)
In reply to: Arch Linux and (the lack of) package signing by hickinbottoms
Parent article: Arch Linux and (the lack of) package signing

Gentoo has manifest checksums which need to be updated when the recipe is. This is vulnerable to compromise and of course assumes the developer has checked their copy of the upstream tarball hasn't been comprised.

One mitigation would be move from rsync'ing the portage tree (which I believe is still held in CVS) to using a git tree instead. At least this way you can be sure* the metadata hasn't been tampered with between syncs. Of course you still depend on the developer doing due diligence on the first tree.

I'm not sure if the nature of the distribution (being source based) widens or narrows the attack surface.

* YMMV, I don't believe anyone has managed an attack on a git repo yet.

Gentoo Mitigations?

Posted Mar 24, 2011 13:36 UTC (Thu) by hickinbottoms (subscriber, #14798) [Link]

Indeed, but of course there's no private key signature element to the manifest, and the manifest is held on the same mirror as the ebuild ('recipe'), which includes the location to download the source from.

This makes it a trivial matter to replace packages without end-user detection if you have write access to a mirror (and there are lots of mirrors). This is the same problem reported in the original article on Arch.

I'm sure you knew this but wanted to point it out since I don't think the presence of the manifest does anything other than to aid detection of corruption of the source tarball during or after download - it doesn't help with indicating package authenticity at all.

I believe there have been discussions over a git-based Portage but it's not got anywhere significant as yet, and GPG-based package signing seems to have been discussed for many years but still isn't stable as far as I can tell.

Gentoo Mitigations?

Posted Mar 24, 2011 19:35 UTC (Thu) by quentin.casasnovas (guest, #58238) [Link] (2 responses)

You may want to take a look at Funtoo, a "Gentoo Linux variant personally developed by Daniel Robbins, creator of Gentoo Linux" : it uses git instead of rsync to update the portage tree.

Gentoo Mitigations?

Posted Mar 24, 2011 23:32 UTC (Thu) by blitzkrieg3 (guest, #57873) [Link]

So what? It doesn't mean the packages are signed.

Funtoo

Posted Mar 25, 2011 10:03 UTC (Fri) by alex (subscriber, #1355) [Link]

I did look at Funtoo, unfortunately the git repo (or at least the gentoo mirror side) was just a daily snapshot of the CVS tree. That doesn't give you any confidence that the mirror hasn't been compromised.

Really you want each change to the metadata to be a discreet verifiable commit.

Gentoo Mitigations?

Posted Mar 24, 2011 19:47 UTC (Thu) by vapier (guest, #15768) [Link] (10 responses)

except for when the Manifest itself is signed

anyone who truly cares about security is not going to rely on SHA1 checksums. claiming "use git" is a fix is ridiculous.

plus, you're now syncing the git tree which balloons overhead considerably since the entire history is mirrored and not just the latest set of files. i'm sure the mirrors giving up free space/bandwidth/resources will love that.

Security of a git tree

Posted Mar 25, 2011 10:10 UTC (Fri) by alex (subscriber, #1355) [Link] (9 responses)

Manufacturing a SHA1 collision is certainly doable. Doing it in a way that allows you to modify an individual commit in a git tree while also not breaking git's internal consistency with respect to history is an attack I've not seen done yet.

And of course you can sign tags with GPG for extra confidence.

As far as bandwidth and diskspace is concerned it would be worth doing some tests before ruling it out as less efficient than rsync. The over the air update protocol is fairly efficient and the .git directory is often smaller than the checked out tree as it's fairly heavily compressed. Plus of course as a developer it's really useful to have the whole history of an ebuild available to you when diagnosing issues or trying to understand why something was done.

Security of a git tree

Posted Mar 25, 2011 14:04 UTC (Fri) by foom (subscriber, #14868) [Link] (3 responses)

> Manufacturing a SHA1 collision is certainly doable.

Really? Isn't it still only theoretical?

SHA1

Posted Mar 25, 2011 15:54 UTC (Fri) by alex (subscriber, #1355) [Link]

I was going from memory but it seems so. Having said that there is a long road from generating collisions to a feasible attack. However from a crypto point of view you are no longer being protected by the maths ;-)

Security of a git tree

Posted Mar 26, 2011 20:39 UTC (Sat) by smurf (subscriber, #17840) [Link] (1 responses)

SHA1 is broken WRT collisions, i.e. you can find (with a lot of effort) two "random" bytestrings which hash to the same SHA1.

That's not the same as finding a bytestring which hashes to a given SHA1, which is still easier than to find a bytestring with, together with a given ASCII pre- and postamble, will match that given SHA1.

I don't think there's a feasible attack for the latter. But as SHA1 is considered "broken enough" that it should be phased out, AFAIK current efforts on one-way hashes are more focused on trying to break the several candidates for SHA's replacement, than to break SHA1 'even more'.

Security of a git tree

Posted Mar 28, 2011 11:01 UTC (Mon) by nye (subscriber, #51576) [Link]

>SHA1 is broken WRT collisions, i.e. you can find (with a lot of effort) two "random" bytestrings which hash to the same SHA1.

In principle yes, but nobody's ever actually done it with full SHA1 - until it gets a bit more broken than it currently is, going beyond proof-of-concept attacks on much reduced versions of SHA1 would still require more computing power than is currently feasible.

>But as SHA1 is considered "broken enough" that it should be phased out

True, it would be a bad choice for something new, but things aren't so terribly bad for SHA-1 yet - hell, there aren't even any pre-image attacks for *MD5* yet AFAIK and that's been considered utterly broken for *years*.

Security of a git tree

Posted Mar 29, 2011 18:34 UTC (Tue) by vapier (guest, #15768) [Link] (4 responses)

signing a SHA1 doesnt increase confidence in SHA1 in any way. it's still a SHA1.

you missed the "resources" aspect. high compression means significantly higher cpu/mem usage which makes scaling up much harder. plus, our mirrors now have to run a git daemon to do mirroring ? it just doesnt work out.

as a developer, you can mirror the VCS tree yourself.

Security of a git tree

Posted Mar 30, 2011 2:08 UTC (Wed) by smurf (subscriber, #17840) [Link] (3 responses)

You don't need a git server for mirriring a git archive.
That works quite well with http.

Security of a git tree

Posted Apr 3, 2011 2:52 UTC (Sun) by vapier (guest, #15768) [Link] (2 responses)

i dont think you've ever used git over http. the performance is downright awful for even small repos.

Security of a git tree

Posted Apr 3, 2011 6:17 UTC (Sun) by smurf (subscriber, #17840) [Link] (1 responses)

I don't think you've heard of "git update-server-info".
It creates a few index files which speed up the job considerably.
(It's typically run from the post-update hook in the shared repository.)

Security of a git tree

Posted Apr 3, 2011 7:37 UTC (Sun) by jrn (subscriber, #64214) [Link]

Presumably he has, since git refuses to fetch over HTTP without it.

Perhaps the servers you've been connecting to use the (relatively) new "smart" HTTP support, which negotiates which objects to send using a CGI script.