[Pkg-gmagick-im-team] Bug#674718: imagemagick: incorrect handling of flattening small GIF frames

[Andrew Deason]

Package: imagemagick
Version: 8:6.7.4.0-5
Severity: important
Tags: patch

Marked as 'important' since I'm not really sure if this is considered a
security issue or not. Change as appropriate.

The following command generates an unexpectedly very large image for me:

convert -flatten -geometry '217x159!' 'foo.gif[0]' foo.jpg

using the attached foo.gif file. Depending on the relevant sizes, this
can either cause the command to SIGBUS (e.g. if /tmp/ runs out of space
when using the pixel cache), or it just generates a very large .jpg.
The expected output is a rather small 217x159 jpg image.

This appears to be because CloneImage scales the image->page size, in
addition to the position and other parameters. In the given GIF, the
logical screen size is 217x159, but the size of the first image block is
much smaller (like 1x4, or something like that? I don't remember).

So, in CloneImage, we have 217 columns and 159 rows. We scale
image->page.width, for instance, by 217/1, resulting in a page width of
217*217. And when we try to flatten all of the layers to generate the
resulting jpg, we get a really huge jpg, since we write the whole size
of the image->page.

The attached patch fixes this by just setting the cloned image page size
to the given number of columns and rows. Scaling the page x and y
coordinates I believe is still correct. I have no idea if scaling the
image->tile_offset is correct or not, since I'm not sure what it is, but
since it appears to be an offset, I would guess 'yes'.

I would get this checked out by someone more familiar with ImageMagick,
since I don't know if this patch breaks something else. I _think_ this
is approximately what GraphicsMagick does, but I'm not too sure; at
least, GraphicsMagick does not have the same issue.

The reason I say this might be considered a security issue is that this
may be used to bypass image size restrictions, and can potentially take
up a large amount of memory or disk when running 'convert' commands
against user input. ImageMagick is often used for generating thumbnails
for user-generated content, for instance, and a bug like this can result
in huge thumbnails from small images, or crashing the process that
generates them. I don't know if that's really a serious concern, though.

-- 
Andrew Deason
adeason at dson.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: im-no-scale-page-size.patch
Type: text/x-diff
Size: 1785 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gmagick-im-team/attachments/20120526/a278e3f8/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: foo.gif
Type: image/gif
Size: 63 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gmagick-im-team/attachments/20120526/a278e3f8/attachment.gif>