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 adea...@dson.org
>From c37821aab3760ad2db23c5375c9c4eb56300f18d Mon Sep 17 00:00:00 2001
From: Andrew Deason <adea...@dson.org>
Date: Sat, 26 May 2012 15:26:08 -0500
Subject: [PATCH] Do not scale page size in CloneImage
If we give CloneImage an image whose width/height is much smaller than
the page width/height, currently CloneImage can make the resulting
cloned page much larger than the specified columns/rows. This can
result in surprisingly huge images after an operation like:
convert -flatten -geometry '200x100!' 'foo.gif[0]' bar.jpg
Since we try to write out the full extents of the image page for the
result. So intead, specify the page width/height as the given number
of columns and rows, to limit the image size to what was requested.
---
magick/image.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/magick/image.c b/magick/image.c
index 92baace..53c8ab0 100644
--- a/magick/image.c
+++ b/magick/image.c
@@ -857,11 +857,11 @@ MagickExport Image *CloneImage(const Image *image,const size_t columns,
clone_image->mask=CloneImage(image->mask,0,0,MagickTrue,exception);
}
scale=(MagickRealType) columns/(MagickRealType) image->columns;
- clone_image->page.width=(size_t) floor(scale*image->page.width+0.5);
+ clone_image->page.width=columns;
clone_image->page.x=(ssize_t) ceil(scale*image->page.x-0.5);
clone_image->tile_offset.x=(ssize_t) ceil(scale*image->tile_offset.x-0.5);
scale=(MagickRealType) rows/(MagickRealType) image->rows;
- clone_image->page.height=(size_t) floor(scale*image->page.height+0.5);
+ clone_image->page.height=rows;
clone_image->page.y=(ssize_t) ceil(scale*image->page.y-0.5);
clone_image->tile_offset.y=(ssize_t) ceil(scale*image->tile_offset.y-0.5);
clone_image->columns=columns;
--
1.7.10
<<attachment: foo.gif>>
