Re: kernel.org tarball/patch signature files

[Jari Ruusu <jariruusu@users.sourceforge.net>]

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.

If I remember correctly, newer versions of OpenSSH disable compression
before authentication. They do that to pre-emptively close attacks resulting
yet unidentified bugs in decompression code.

-- 
Jari Ruusu  1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9  DB 1D EB E3 24 0E A9 DD