Bug 285941 - Heap overflow in ImageMagick's PICT coder
Heap overflow in ImageMagick's PICT coder
Status: CLOSED WONTFIX
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
http://bugs.debian.org/cgi-bin/bugrep...
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-11 09:36 EDT by Lubomir Kundrak
Modified: 2008-02-26 08:14 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-26 08:14:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
A broken PICT image that triggers ImageMagick's heap corruption (22.36 KB, application/octet-stream)
2007-09-11 09:37 EDT, Lubomir Kundrak
no flags Details
Another broken PICT image that triggers ImageMagick's heap corruption (22.36 KB, application/octet-stream)
2007-09-11 09:38 EDT, Lubomir Kundrak
no flags Details
A different reproducer for a possible out-of-bound write. (22.36 KB, application/octet-stream)
2007-09-11 09:56 EDT, Lubomir Kundrak
no flags Details

  None (edit)
Description Lubomir Kundrak 2007-09-11 09:36:21 EDT
Description of problem:

Attemting to display a fuzzed PICT file results in following:

(gdb) run broken.pict
[Thread debugging using libthread_db enabled]
[New Thread -1208674624 (LWP 32276)]

Program received signal SIGXFSZ, File size limit exceeded.
[Switching to Thread -1208674624 (LWP 32276)]
0x00110402 in __kernel_vsyscall ()
(gdb) up
#1  0x00de2ad2 in pwrite64 () from /lib/libpthread.so.0
(gdb) up
#2  0x0014621c in WriteCacheRegion (file=9, buffer=0x28237b "", length=1,
offset=5222670517311) at magick/cache.c:1069
1069        count=pwrite(file,buffer+i,(size_t) Min(length-i,(MagickSizeType)
(gdb) up
#3  0x00149fc6 in ExtendCache (image=0x9a0e158, length=5222670517312) at
magick/cache.c:2925
2925        count=WriteCacheRegion(cache_info->file,(const unsigned char *) "",1,
(gdb) 

Looking at the ExtendCache()'s length argument, it has obviously been corrupted.
The Debian bug (see URL) has more information:

Rectangular coordinates are read from the input file, and used to
calculate the numbers of rows and columns to read in. Due to missing
validation of input coordinates, results can wrap and yield excessive
numbers of rows and columns that are inconsistent with other input
values, and allow to overflow a heap buffer with user-supplied input
later on. I haven't analysed in detail, but potentially this bug could
be exploitable. Fix attached.

Version-Release number of selected component (if applicable):

ImageMagick-6.2.8.0-3.el5.4
Comment 1 Lubomir Kundrak 2007-09-11 09:37:47 EDT
Created attachment 192511 [details]
A broken PICT image that triggers ImageMagick's heap corruption
Comment 2 Lubomir Kundrak 2007-09-11 09:38:31 EDT
Created attachment 192521 [details]
Another broken PICT image that triggers ImageMagick's heap corruption
Comment 3 Lubomir Kundrak 2007-09-11 09:56:10 EDT
Created attachment 192541 [details]
A different reproducer for a possible out-of-bound write.

This one, as well as the previous one was grabbed from
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=414370

Might be a different problem:

(gdb) run broken3.pict 
[Thread debugging using libthread_db enabled]
[New Thread -1208858944 (LWP 32480)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208858944 (LWP 32480)]
0x001ee340 in CopyMagickMemory (destination=0x8852e90, source=0x41eee0,
size=688) at magick/memory.c:405
405	    return(memcpy(destination,source,size));
(gdb) bt
#0  0x001ee340 in CopyMagickMemory (destination=0x8852e90, source=0x41eee0,
size=688) at magick/memory.c:405
#1  0x004181e1 in DecodeImage (image_info=0x8826440, blob=0x8837f30,
image=0x883b160, bytes_per_line=203, bits_per_pixel=1) at coders/pict.c:513
#2  0x00419b80 in ReadPICTImage (image_info=0x8826440, exception=0xbfbffc94) at
coders/pict.c:1110
#3  0x0016a211 in ReadImage (image_info=0x8820320, exception=0xbfbffc94) at
magick/constitute.c:389
#4  0x0034eb41 in DisplayImageCommand (image_info=0x8820320, argc=2,
argv=0x88154c0, wand_unused_metadata=0x0, exception=0xbfbffc94) at
wand/display.c:498
#5  0x080489f3 in main (argc=2, argv=0xbfbffd64) at utilities/display.c:132
#6  0x00ba5f70 in __libc_start_main () from /lib/libc.so.6
#7  0x080487a1 in _start ()
(gdb)
Comment 4 Norm Murray 2008-01-11 01:59:25 EST
On RHEL 2.1:

[root@a]# identify ~/broken-files/broken-1-bz285941.pict
Segmentation fault
[root@a]# identify ~/broken-files/broken-2-bz285941.pict
Segmentation fault
[root@a]# identify ~/broken-files/broken-3-bz285941.pict
/root/broken-files/broken-3-bz285941.pict PICT 203x152 DirectClass 16-bit 22kb
0.0u 0:01
[root@a]# convert ~/broken-files/broken-3-bz285941.pict /tmp/foo.jpg
convert: invalid colormap index (/root/broken-files/broken-3-bz285941.pict) [No
such file or directory].

So here we have only the first two having problems. So at least the partial
patch against 2.1 needs to have this segment in it: 
@@ -1032,6 +1032,8 @@ static Image *ReadPICTImage(const ImageI
                 for (i=0; i <= (length-2); i++)
                   (void) ReadBlobByte(image);
               }
+           if (bytes_per_line == 0)
+             ThrowReaderException(CorruptImageError,"ImproperImageHeader",image);
             if ((code != 0x9a) && (code != 0x9b) &&
                 (bytes_per_line & 0x8000) == 0)
               pixels=DecodeImage(image_info,image,tile_image,bytes_per_line,1);

Which then gets it past these two corrupt images. 
Comment 10 Lubomir Kundrak 2008-02-26 08:14:17 EST
So this is heap overflow that can't overwrite any pointer to function or
anything that would make it expoitable.

Note You need to log in before you can comment on or make changes to this bug.