Message-ID: <20111025014911.GC22764@kroah.com>
Date:	Tue, 25 Oct 2011 03:49:11 +0200
From:	Greg KH <greg@...ah.com>
To:	Jari Ruusu <jariruusu@...rs.sourceforge.net>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: kernel.org tarball/patch signature files

On Sun, Oct 23, 2011 at 05:07:51PM +0300, Jari Ruusu wrote:
> Greg KH wrote:
> > On Sun, Oct 23, 2011 at 02:17:20PM +0300, Jari Ruusu wrote:
> > > Wrong order to verify compressed tarball/patch:
> > >
> > > (1) Feed potentially maliciously formatted data to decompressor, and exploit
> > >     any undiscovered/unpatched vulnerability in decompressor implementation.
> > > (2) Verify decompressed output.
> > >
> > > Much better order would be:
> > >
> > > (1) Verify compressed data.
> > > (2) Feed trusted data to decompressor.
> > >
> > > So, would it be possible to have multiple signature files like this? Please.
> > >
> > > patch-3.X.Y.bz2
> > > patch-3.X.Y.bz2.sign
> > > patch-3.X.Y.gz
> > > patch-3.X.Y.gz.sign
> > > patch-3.X.Y.xz
> > > patch-3.X.Y.xz.sign
> > 
> > Nope, sorry, let's try this way instead.  That way we only have to
> > generate one signature, not 3.
> 
> How about one signed message that contains multiple SHA256 sums or whatever?
> 
>   sha256sum patch-3.X.Y.{bz2,gz,xz} | gpg --clearsign -a >patch-3.X.Y.sign
> 
> That allows verification before decompression.
> 
> > If you are really worried about decompressor bugs, then run them in a
> > virtual machine/chroot :)
> 
> I am not amused.
> 
> Greg, please put your security hat on, and look at this from security point
> of view. Decompression after verify removes/closes attacks utilizing yet
> unidentified decompressor bugs or security flaws.

Please realize that we are building this whole thing back up from
scratch here, and some services are not possible to do just yet.

Also realize our constraints.  I don't want to, and in fact it's almost
impossible to, upload the 3 compressed tarballs over a large number of
internet connections that I have access to as I travel around the world.
So, given that you don't want all kernel release maintainers to store
their private keys on the server (remember what just happened), the
ability to generate that signature would be a pretty difficult thing,
right?

So, we are working on a proposal that has a "throw away" signature for
the compressed files, that can be verified by people after they download
the tarball to ensure that they didn't get something "odd".  That will
handle the sha256sum, and allow us to add future compression types with
no need to regenerate the "real" signatures from the original release.

The real check, to verify that this tarball really came from "me" should
be done on the uncompressed tarball, which is what I can sign, and it is
something that you, or anyone else, can reliable duplicate on their own
by just using git and not even downloading the tarball at all.

In other words, we just saved you a MASSIVE bandwidth transation for all
of your future kernel downloads, and you can reliable know that the
tarball you have in your system is what is on the kernel.org servers
without you even having to download it yourself and run those
decompression tools that you don't trus.

And still you complain :)

Hope this helps explain why this is the way it is.  It's as if people
think we are just making it up as we go along...

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists