Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Neil Williams <codehelp <at> debian.org>
Subject: Re: leaks in our only-signed-software fortress
Newsgroups: gmane.linux.debian.devel.general
Date: Saturday 18th February 2012 16:17:12 UTC (over 5 years ago)
On Sat, 18 Feb 2012 15:59:38 +0200
Christoph Anton Mitterer  wrote:

> Am 18.02.2012 10:11, schrieb Teus Benschop:
> > To put things in perspective, I just wonder how strong this 
> > 'fortress'
> > really is, and whether this strength is only in our perception or
> > whether it is real. Let me give just one example: A developer 
> > downloads
> > a tarball from an upstream source, configures it, and does make 
> > install,
> > yet has not even once checked whether this tarball is secure or is 
> > not a
> > root kit.

Detecting a root kit in downloaded source isn't trivial. If the package
has completely changed and has been *replaced* with a toolkit, then any
maintainer will notice that it doesn't build the files expected. A
determined attack which tries to embed a root kit within an existing
package/binary would be much more difficult for anyone to pick up,
potentially even upstream. If a binary file built for the previous
version of the upstream is a few Kb bigger in the next release, no
maintainer is going to see that as anything more than entirely
expected of a new upstream release.
 
> This is true but...
> a) this would be a general attack against all people, which are usually 
> a tiny bit harder to do, then the local sysadmin just hacking 
> colleagues..

So what is the point of the entire thread? Downloading upstream sources
is a general thing for everyone using that package but it is done by
one person (usually) and (usually) without any upstream checksums. It's
a complete non-issue because there is 0% chance of getting every
conceivable upstream team to implement anything like this.

There may be other clues (file naming conventions, layout styles, weird
compile messages appearing etc.) but none of those are reliable.

> b) as everyone is affected then (all users of the package),... there is 
> a greater chance of notifying it

But it is still down to chance. Overall, it's not something that I'm
going to lose any sleep over. There's no way that I'll be asking
my upstream teams to even consider it, nor would I implement it for my
own upstream projects. I happen to use upstream sites which provide
something like this but their security models aren't perfect.

I used to provide detached GnuPG signatures alongside my uploaded
source tarballs but nobody cared or even noticed if I inadvertently
broke the signature. (This is for packages which regularly got
downloaded for inclusion into Fedora, ArchLinux, Gentoo and numerous
other distros other than Debian/Debian-based ones which get the source
directly from me.)

Honestly, nobody cares.

> most important...
> c) the ideal situation would of course be, that the maintainer has a 
> good relationship to upstream, perhaps even met them in person, 
> exchanged OpenPGP keys with them and uses those (or weaker means[0]) to 
> verify every single download.

Completely unrealistic for most maintainers. Now, I could be really smug
here and say that for some of my packages, I have absolute and airtight
security between maintainer and upstream but that's only because I am
sole maintainer and sole upstream.. (if you want better security
than that, keep dreaming) .. but I also have other packages where
upstream provide no checksums whatsoever. I've been lucky enough to
meet one member of one of those upstream teams once (at a conference ~3
yrs ago which I haven't been able to attend since) but we had much more
important stuff to discuss than signing / checksumming the download
directory.

Besides, meeting someone once with little chance of ever meeting them
again is not a particularly strong indication that I should sign their
GnuPG key (which is why I don't attend mass keysignings any longer).

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/
 
CD: 3ms