lkml.org 
[lkml]   [2011]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: kernel.org tarball/patch signature files
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


\
 
 \ /
  Last update: 2011-10-23 16:11    [W:0.070 / U:1.396 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site