Description of problem: A fuzzed XCF file causes this to happen: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208990016 (LWP 5846)] 0x00416f49 in load_tile (image=0x8d57e30, tile_image=0x8d60320, inDocInfo=0xbfbd5450, inLayerInfo=0x8d4bc90, data_length=8389203) at coders/xcf.c:327 327 q->red = ScaleCharToQuantum(xcfdata->red); (gdb) I tend to thing that this might be exploitable. Norm, could you please have a closer look? Additional info: This is the cycle where the overflow happens. 313 q=SetImagePixels(tile_image,0,0,tile_image->columns,tile_image->rows); 314 315 /* we have to copy the pixels individually since IM uses a different 316 format PixelPacket on different platforms - not to mention 317 different QuantumDepths! 318 */ 319 for ( i=0; i < (long) nmemb_read_successfully;i++ ) { 320 if ( inDocInfo->image_type == GIMP_GRAY ) { 321 q->red = ScaleCharToQuantum(*graydata); 322 q->green = ScaleCharToQuantum(*graydata); 323 q->blue = ScaleCharToQuantum(*graydata); 324 q->opacity = ScaleCharToQuantum((Quantum) (255-inLayerInfo->opacity)); 325 graydata++; 326 } else if ( inDocInfo->image_type == GIMP_RGB ) { 327 q->red = ScaleCharToQuantum(xcfdata->red); 328 q->green = ScaleCharToQuantum(xcfdata->green); 329 q->blue = ScaleCharToQuantum(xcfdata->blue); 330 q->opacity = (Quantum) ((int) xcfdata->opacity==0 ? TransparentOpacity : ScaleCharToQuantum((Quantum) (255-inLayerInfo->opacity))); 331 332 xcfdata++; 333 }; 334 335 q++; 336 } Version-Release number of selected component (if applicable): ImageMagick-6.2.8.0-3.el5.4
Created attachment 192731 [details] The reproducer for the out-of-bound write to ImageMagick's heap
Investigation on 2.1 shows that ImageMagick doesn't have a native xcf handler, but instead is relying upon gimp-perl's xcftopnm functionality, and the error in handling this image is the same as handling a known good xcf file: # identify ~/working-images/image.xcf protocol error (1) at /usr/lib/perl5/site_perl/5.6.0/i386-linux/Gimp/Net.pm line 66. identify: Unable to open file (/tmp/magicGpe6SE/fileEsPyVM) [No such file or directory]. identify: Missing an image file name. So this does not have impact for 2.1
GraphicsMagick is reportedly affected too, Cc'ing maintainer.
Reporter changed to security-response-team by request of Jay Turner.
This has been corrected in Red Hat Enterprise Linux 3, 4, and 5: https://access.redhat.com/security/cve/CVE-2008-1096