Bug 285861 - (CVE-2008-1097) CVE-2008-1097 Memory corruption in ImageMagick's PCX coder
CVE-2008-1097 Memory corruption in ImageMagick's PCX coder
Status: NEW
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...
impact=moderate,source=debian,public=...
: Security
Depends On: 411331 411341 411361 411371 411381 411391
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-11 09:10 EDT by Red Hat Product Security
Modified: 2009-10-23 15:03 EDT (History)
3 users (show)

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


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

  None (edit)
Description Lubomir Kundrak 2007-09-11 09:10:34 EDT
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 09:24:23 EDT
Created attachment 192471 [details]
A broken PCX image that triggers ImageMagick's heap corruption
Comment 2 Norm Murray 2008-01-10 22:45:38 EST
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 10:13:36 EDT
GraphicsMagick is reportedly affected too, Cc'ing maintainer.
Comment 8 Red Hat Bugzilla 2009-10-23 15:03:12 EDT
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.