Bug 286411 (CVE-2008-1096)
| Summary: | CVE-2008-1096 Out of bound write in ImageMagick's XCF coder | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Red Hat Product Security <security-response-team> | ||||
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> | ||||
| Status: | CLOSED ERRATA | QA Contact: | |||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | unspecified | CC: | andreas, bnocera, nmurray | ||||
| Target Milestone: | --- | Keywords: | Security | ||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| URL: | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=414370 | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2013-04-10 20:37:25 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | 411341, 411361, 411371, 411381, 411391 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
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 |
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