Re: Zip Bomb vulnerability questions

On Thu, 9 Jul 2020, Przemysław Sobala wrote:

> Hi
> GraphicsMagick tries to open compressed files which makes it vulnerable for Zip
> Bomb <https://en.wikipedia.org/wiki/Zip_bomb> attacks.
> Eg.:
> 14:45:13 0:0.001810  0.000u 4654 blob.c/ImageToFile/2396/Blob:
>  Copying from Blob stream to file /tmp/gmdUEvhK
>
> [Uncompressing malicious file that lasts forever and consumes lots of memmory]

That is annoying!

> 1. Is there a possibility to set a black/white list of un/supported formats
> to support only eg. JPG, PNG, GIF or to disable support of compressed files?

The problem with compressed files is that you can't see for sure what 
they contain before at least decompressing part of the file.  If the 
file comes from a pipe then the only way to succeed is then decompress 
from the pipe to a temporary file (or into RAM).  We would support 
using gzip compressed files directly but it was discovered that using 
its "seek" functionality is not very reliable or efficient.

There is not currently a way via a configuration file.  There is a 
MAGICK_CODER_STABILITY environment variable which may be set to the 
string PRIMARY, STABLE, UNSTABLE, or BROKEN, which filters out coders 
based on my opinion of how safe they are and their usefulness.

Set the environment variable and then do 'gm convert -list format' to 
see what formats are then available.

Beyond this, if you do a modules based build, you can delete the 
installed modules you don't trust.

Yes, I know that we should have a config file for this but the 
approach ImageMagick uses seems unnecessarily complex.  I do not like 
it that OS distributions (e.g. Ubuntu) provide their own default 
config file which severely limits ImageMagick functionality.

> 2. After configuring GM without the support of zlib (un)compressing files
> is not supported any more, but so is reading/writing PNG files...

If you were to edit magick/blob.c and add the line

#undef HasZLIB

before the line which says

#if defined(HasZLIB)

then I think that the endless decompression to a temporary file will 
no longer be an issue.

> 3. PNG uses a compression algorithm. Is GM vulnerable to malicious
> (Compression Bomb) PNG files?
> I think I saw somewhere in PNG decoder's code, inside GM, a part where it
> checks compression ratio and fails to read file if it's below some
> arbitrary value. If it's correct, it should protect us from malicious PNG
> files.

GraphicsMagick gets tested every day by Google's oss-fuzz, and it went 
through many other fuzz-testing efforts, as well as testing with known 
malicious PNG files.  It is true that small files which claim 
exceedingly high compression ratio are rejected.  PNG is supposed to 
be good at compression so for a real file an exceedingly high 
compression ratio would be appreciated.  The problem with arbitrary 
limits is that some valid files may be rejected.

There are limits which may be set on total image pixels and 
rows/columns.  This is often the best safeguard.

There is no warranty, but I think that PNG is pretty safe in the 
latest release, and definitely in the latest snapshot version.

Bob
-- 
Bob Friesenhahn
[email protected], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt

_______________________________________________
Graphicsmagick-help mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/graphicsmagick-help