RPM: signing uncompressed data instead of signed data?

[Andre Robatino]

Bruno Wolff III wrote:

>  Uncompressing hostile data is generally not a good thing to be
> doing.
>  From that aspect it makes more sense to sign the compressed payload. 
I was thinking that since the signature check usually passes, the data
could be uncompressed into a cache, checked there, then copied into
place (assuming the check passes). If the data is capable of escaping
from that sandbox before being checked, that's a serious security bug in
the compression software that should be fixed in any case.

(Sorry for not responding in-thread. Gmane isn't updating its list of
existing threads.)

[Bruno Wolff III]

On Thu, Nov 11, 2010 at 09:29:54 -0500,
  Andre Robatino <robatino(a)fedoraproject.org&gt; wrote:
>  Bruno Wolff III wrote:
>  
>  > Uncompressing hostile data is generally not a good thing to be doing.
>  > From that aspect it makes more sense to sign the compressed payload.
>  
>  I was thinking that since the signature check usually passes, the data
>  could be uncompressed into a cache, checked there, then copied into
>  place (assuming the check passes). If the data is capable of escaping
>  from that sandbox before being checked, that's a serious security bug in
>  the compression software that should be fixed in any case. 
The issue is the uncompression itself rather than the resulting uncompressed
data being used. It is easy to do a DOS by compressing a very large file
of constant data and having the victum fill up their disk. Also compression /
decompression seems to be an area where proper paranoia isn't practiced and
malformed data can cause problems. There have been several cases of libraries
handling compressed image formats allowing arbitrary execution of code when
operating on trojan images. I suspect that historically the people writing
this kind of code were more interested in speed than security.