Bug 285861 (CVE-2008-1097)

Created attachment 192471 [details]
A broken PCX image that triggers ImageMagick's heap corruption

In RHEL 4, identify, this backtraces as:
#0  0x0071bbc0 in _int_malloc () from /lib/tls/libc.so.6
#1  0x0071d6e1 in malloc () from /lib/tls/libc.so.6
#2  0x0020fe83 in AcquireMagickMemory (size=8) at memory.c:316
#3  0x001f1af8 in AppendElementToLinkedList (list_info=0xfffffff0, 
    datum=0x8b7d760) at hashmap.c:163
#4  0x0016e6e5 in GetConfigurePaths (filename=0x351ee9 "locale.mgk", 
    exception=0xbff69840) at configure.c:599
#5  0x00209aa0 in GetLocaleOptions (filename=0x351ee9 "locale.mgk", 
    exception=0xbff69840) at locale.c:524
#6  0x0020a852 in LoadLocaleLists (filename=Variable "filename" is not available.
) at locale.c:1028
#7  0x0020aac8 in GetLocaleInfo_ (
    tag=0xbff69860 "Exception/Corrupt/Image/Error/InvalidColormapIndex/", 
    exception=0xbff69840) at locale.c:647
#8  0x0020aba3 in GetLocaleMessage (
    tag=0xbff6a8a0 "Exception/Corrupt/Image/Error/InvalidColormapIndex")
    at locale.c:466
#9  0x001e6854 in GetLocaleExceptionMessage (severity=CorruptImageError, 
    tag=0x34162b "InvalidColormapIndex") at error.c:434
#10 0x001e6ded in ThrowMagickException (exception=0x8a04e28, 
    module=0x77f2f97 "M\b\213\201�", function=0x77f2f97 "M\b\213\201�", 
    line=125775767, severity=CorruptImageError, tag=0x77f2f97 "M\b\213\201�")
    at error.c:842
#11 0x001f75b7 in SyncImage (image=0x8a01c70) at ../magick/color_private.h:20
#12 0x002c88bd in ReadPCXImage (image_info=0x87b5de0, exception=0xbff6ec10)
    at pcx.c:583
#13 0x0017f559 in ReadImage (image_info=0x87afc68, exception=0xbff6ec10)
    at constitute.c:5549
#14 0x00248752 in ReadStream (image_info=0x87abb78, 
    stream=0x77f2f97 <png_push_read_chunk+1145>, exception=0xbff6ec10)
    at stream.c:501
#15 0x00177d0a in PingImage (image_info=0x87a7a88, exception=0xbff6ec10)
    at constitute.c:3133
#16 0x001f4009 in IdentifyImageCommand (image_info=0x87a1968, argc=2, 
    argv=0x87a17f8, metadata=0xbff6ec0c, exception=0xbff6ec10)
    at identify.c:279
#17 0x08048a11 in main (argc=2, argv=0xbff6ecd4) at identify.c:112
#18 0x006cdde3 in __libc_start_main () from /lib/tls/libc.so.6
#19 0x080488e1 in _start ()

and where the exception is thrown is:
(gdb) l
15      static inline IndexPacket ConstrainColormapIndex(Image *image,
16        const unsigned long index)
17      {
18        if (index >= image->colors)
19          {
20            (void) ThrowMagickException(&image->exception,GetMagickModule(),
21              CorruptImageError,"InvalidColormapIndex",image->filename);
22            return(0);
23          }
24        return((IndexPacket) index);
(gdb) 

Exploitability would seem low given that we're already in an abort codepath
here, but the nasty bit is that in the next frame down the incoming args are:
#10 0x001e6ded in ThrowMagickException (exception=0x8a04e28, 
    module=0x77f2f97 "M\b\213\201�", function=0x77f2f97 "M\b\213\201�", 
    line=125775767, severity=CorruptImageError, tag=0x77f2f97 "M\b\213\201�")
    at error.c:842

Which don't match up to the values before the call. 

recent ImageMagick is catching this with additional header checks:
+    if ((image->columns == 0) || (image->rows == 0) ||
+       (pcx_info.bits_per_pixel == 0))
+      ThrowReaderException(CorruptImageError,"ImproperImageHeader",image);

Which catches the problem on 2.1 (as a first testbed) and aborts out as in this
broken image the bits_per_pixel is 0. 

GraphicsMagick is reportedly affected too, Cc'ing maintainer.

Reporter changed to security-response-team by request of Jay Turner.