Arch Linux and (the lack of) package signing

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

Unless I'm out of date I believe Gentoo has also always suffered this, and continues to do so.

Gentoo Mitigations?

Posted Mar 24, 2011 12:28 UTC (Thu) by alex (subscriber, #1355) [Link] (15 responses)

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.

Arch Linux and (the lack of) package signing

Posted Mar 24, 2011 15:50 UTC (Thu) by tetromino (guest, #33846) [Link] (4 responses)

> Unless I'm out of date I believe Gentoo has also always suffered this, and continues to do so.

You are many years out of date :) Gentoo's portage has had the ability to use GPG to sign and verity package manifests since 2004: http://www.gentoo.org/news/20041021-portage51.xml

What is true is that there seems to be no policy requiring Gentoo developers to sign manifests, and as a result, many developers never bother to do so and thousands of packages remain unsigned.

Gentoo package signing

Posted Mar 24, 2011 16:39 UTC (Thu) by alex (subscriber, #1355) [Link]

So I assume if old packages aren't signed portage will either allow them or refuse to install them depending on the level of the feature?

/me makes a note to enable the gpg feature.

Arch Linux and (the lack of) package signing

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

> You are many years out of date :)

I suspected as much! However, I looked into this feature today and it doesn't appear to be enabled in the currently marked-stable portage (on my system, at least):

> # emerge ...whatever...
> FEATURES variable contains unknown value(s): gpg
> Portage 2.1.9.42 (default/linux/x86/10.0, gcc-4.4.5, glibc-2.11.3-r0, 2.6.35-gentoo-r12 i686)

Still, as you say it counts for little if most of the software isn't signed by the mai

Arch Linux and (the lack of) package signing

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

hmm, should be trivial to start enforcing manifest signing in the main tree. it's trivial to setup keys after all.

$ find *-* -maxdepth 2 -name Manifest | wc -l
14438
$ find *-* -maxdepth 2 -name Manifest -exec grep -l 'BEGIN PGP SIGNATURE' {} + | wc -l
6032

that is fairly abysmal ...

Arch Linux and (the lack of) package signing

Posted Mar 25, 2011 2:53 UTC (Fri) by nicooo (guest, #69134) [Link]

It seems like there are some issues that still need to be resolved.