Bug 285861 (CVE-2008-1097) - CVE-2008-1097 Memory corruption in ImageMagick's PCX coder
Summary: CVE-2008-1097 Memory corruption in ImageMagick's PCX coder
Status: NEW
Alias: CVE-2008-1097
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL: http://bugs.debian.org/cgi-bin/bugrep...
Whiteboard: impact=moderate,source=debian,public=...
Keywords: Security
Depends On: 411331 411341 411361 411371 411381 411391
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-09-11 13:10 UTC by Red Hat Product Security
Modified: 2019-06-08 12:22 UTC (History)
3 users (show)

(edit)
Clone Of:
(edit)
Last Closed:


Attachments (Terms of Use)
A broken PCX image that triggers ImageMagick's heap corruption (89.39 KB, application/octet-stream)
2007-09-11 13:24 UTC, Lubomir Kundrak
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2008:0145 normal SHIPPED_LIVE Moderate: ImageMagick security update 2008-04-17 01:32:11 UTC
Red Hat Product Errata RHSA-2008:0165 normal SHIPPED_LIVE Moderate: ImageMagick security update 2008-04-17 01:31:44 UTC

Description Lubomir Kundrak 2007-09-11 13:10:34 UTC
Description of the probem:

Attemting to display a broken PCX file results in a heap corruption:

Steps to reproduce:

(gdb) run broken.pcx 
[Thread debugging using libthread_db enabled]
[New Thread -1208564032 (LWP 31972)]
*** glibc detected *** /usr/bin/display: malloc(): memory corruption: 0x087e42c0 ***
...
Program received signal SIGABRT, Aborted.
[Switching to Thread -1208564032 (LWP 31972)]
0x00110402 in __kernel_vsyscall ()
(gdb) 

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

ImageMagick-6.2.8.0-3.el5.4

Additional information:

Debian bug referenced in URL might contain more informaion.

Comment 1 Lubomir Kundrak 2007-09-11 13:24:23 UTC
Created attachment 192471 [details]
A broken PCX image that triggers ImageMagick's heap corruption

Comment 2 Norm Murray 2008-01-11 03:45:38 UTC
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. 





Comment 6 Ville Skyttä 2008-03-22 14:13:36 UTC
GraphicsMagick is reportedly affected too, Cc'ing maintainer.

Comment 8 Red Hat Bugzilla 2009-10-23 19:03:12 UTC
Reporter changed to security-response-team@redhat.com by request of Jay Turner.


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