Decompression bomb protection

[masklinn]

"zip bombs" are a somewhat know threat, but it also applies to images and can't be protected against by checking the filesystem size of the data:

• http://www.aerasec.de/security/advisories/decompression-bomb-vulnerability.html provides 2 PNG bomb demos, a 4KB 6000x6000 images decompressing to 100MB in memory and a 44KB 19000x19000 image decompressing to 1GB
• JPEG is somewhat less efficient, but e.g. NASA Visible Earth's Blue Marble has 21600x21600 tiles as small as 5MB (tile A2, southern pacific) decompressing to 1.4GB

This means it's possible to DOS e.g. a web application performing image resizing by sending one of these bombs. As far as I can tell the protection possibilities are limited:

• assert source image sizes before doing any operation which will need the image data, the documentation may benefit from a warning on that subject (similar to warnings about XML vulnerabilities in the Python documentation), Image.open could be augmented with e.g. a maximum_pixels parameter raising an error in case image.h * image.w goes above the specified limit to make this easier for users
• during image loading/decompression, raise an error if the decompressed data size gets above a specific threshold

[wiredfool]

I suspect that a nearly empty image that only included size metadata and enough plausible data to start the decoder would trigger a DOS. Essentially, Image.new allocates the storage before passing it off to the decoder to fill. And that's solely based on the size and the number of bands.

There's now protection in the BMP decoder against that, but the limit is set rather high, 2GP or something like that.

I can see adding a limit to the allocator that would raise an exception if a memory limit was exceeded. I'm not 100% sure that I want to enable it by default -- I suspect that the scientific imaging community would be the ones that would bump up against it in the course of ordinary work.

[d-schmidt]

Big jpegs aren't even a problem if you are using thumbnail(). But we did test our backend with image like Carina Nebula http://hubblesite.org/gallery/album/entire/pr2007016a/warn/
The pngs are interesting in a multi processing environment, Going to run some tests with these.

edit: another thing to note is that Image.open() will not trigger the bombs. Images aren't really loaded until you actually do something with the image.

im = Image.open('evil.png')
if im.size[0] * im.size[1] > arbitary_large_limit:
    raise ImageIsToBigError("image size exceeds limit")
im.do_something()

Should solve this bomb problems just fine.

[masklinn]

Big jpegs aren't even a problem if you are using thumbnail().

Interesting. The issue still exists for other operations though right? And for non-JPEG plugins, unless the author has specifically taken steps to avoid it?

How comes thumbnail works but resize seems to load the whole image in memory? Tricks in the JPEG image plugin?

another thing to note is that Image.open() will not trigger the bombs.

Yes I didn't specifically note it, as the doc states sufficiently clearly that Image.open is a lazy operation and does not decode&load pixel data until they're needed.

Should solve this bomb problems just fine.

It "does", if you know about the issue in the first place. Hence my suggestion to add a warning on the subject in Pillow's documentation, similar to the standard library warning about entity-based attacks on XML parsers. I think that'd be a baseline solution, though I also think protecting users by default (by adding an overridable check directly in Image.open) would be a good idea.

[wiredfool]

JPEG thumbnails are a special case because of the way that JPEG compression works. It's a spatial frequency approach, rather than a raster line compression. If you cut off the frequency low enough, you don't have to read most of the data.

[aclark4life]

Where is the PR for this issue, assuming one exists?

[aclark4life]

Anyone have any interest in working on this for 2.5.0?

[hugovk]

For starters, how about something along the lines of this?
hugovk@ce2955e#diff-3fef5f960d5bd8bdfb9c6fadcf96af22L2100

Image.open() takes a new maximum_pixels parameter, defaulting to some predetermined ARBITARY_LARGE_LIMIT (6000 * 6000 - 1 for testing).

If the image is larger than this, throw an ImageIsTooBigError exception.

This test code:

from PIL import Image

print(1, "No exception:")
im1 = Image.open("picture-100M-6000x6000.png", maximum_pixels=None)

print(2, "No exception:")
im2 = Image.open("picture-100M-6000x6000.png", maximum_pixels=6000*6000)

print(3, "Exception:")
im3 = Image.open("picture-100M-6000x6000.png")

print(4, "End")

Outputs:

(1, 'No exception:')
(2, 'No exception:')
Pixels: 36000000
(3, 'Exception:')
Pixels: 36000000
Traceback (most recent call last):
  File "C:\stufftodelete\test.py", line 10, in <module>
    im3 = Image.open("picture-100M-6000x6000.png")
  File "C:\Python27\lib\site-packages\PIL\Image.py", line 2128, in open
    _compression_bomb_check(im, maximum_pixels)
  File "C:\Python27\lib\site-packages\PIL\Image.py", line 2085, in _compression_bomb_check
    raise ImageIsTooBigError("Image size exceeds limit")
PIL.Image.ImageIsTooBigError: Image size exceeds limit

[hugovk]

See #674.

[d-schmidt]

This would break existing code. I'm all in for an optional parameter, but we can't just throw a new Exception now.

Nokia lumia pictures are already bigger than 36M.

[xmo-odoo]

I'm all in for an optional parameter

That would be no improvement over the current situation.