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.
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.