Messages in this thread | | | Date | Sun, 23 Oct 2011 17:07:51 +0300 | From | Jari Ruusu <> | Subject | Re: 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
| |