Bug 844105 (CVE-2012-3438)

Summary: CVE-2012-3438 GraphicsMagick: png_IM_malloc() size argument
Product: [Other] Security Response Reporter: Kurt Seifried <kseifried>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: andreas, rdieter, tgl
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: impact=low,public=20120727,reported=20120727,source=redhat,cvss2=4.3/AV:N/AC:M/Au:N/C:N/I:N/A:P,fedora-all/GraphicsMagick=affected,epel-all/GraphicsMagick=affected
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-10-15 10:29:22 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On: 844106, 844107    
Bug Blocks: 844110    

Description Kurt Seifried 2012-07-28 19:01:27 EDT
Tom Lane (tgl@redhat.com) found an issue in ImageMagick that is also present 
in GraphicsMagick. Basically CVE-2011-3026 deals with libpng memory 
allocation, limitations have been added so that a bad PNG can't cause the 
system to allocate a lot of memory causing a denial of service. However on 
further investigation of ImageMagick Tom Lane found that PNG malloc 
function (Magick_png_malloc) in turn calls AcquireMagickMemory with an 
improper size argument:

static png_voidp Magick_png_malloc(png_structp png_ptr,png_uint_32 size)
  (void) png_ptr;
  return((png_voidp) AcquireMagickMemory((size_t) size));

Similar code is present in GraphicsMagick:

static png_voidp png_IM_malloc(png_structp png_ptr,png_uint_32 size)
  (void) png_ptr;
  return MagickAllocateMemory(png_voidp,(size_t) size);

This is incorrect, the size argument should be declared png_alloc_size_t 
according to 1.5, or png_size_t according to 1.2.

"As this function stands, it invisibly does the wrong thing for any request 
over 4GB.  On big-endian architectures it very possibly will do the wrong 
thing even for requests less than that. So the reason why the hard-wired 4GB 
limit prevents a core dump is that it masks the ABI mismatch here."

So basically we have memory allocations problems that can probably lead to a 
denial of service.
Comment 1 Kurt Seifried 2012-07-28 19:03:00 EDT
Created GraphicsMagick tracking bugs for this issue

Affects: fedora-all [bug 844106]
Comment 2 Kurt Seifried 2012-07-28 19:03:34 EDT
Created GraphicsMagick tracking bugs for this issue

Affects: epel-all [bug 844107]
Comment 3 Tom Lane 2012-07-29 11:26:06 EDT
I'm told upstream has already committed a fix for this, so you should be able to pull a patch out of their SCM.
Comment 5 Vincent Danen 2012-10-15 10:29:22 EDT
Just to note, that CVE-2012-3437 is for this flaw in ImageMagick, while CVE-2012-3438 is for this flaw in GraphicsMagick.  The initial description does not make it clear that separate CVEs were assigned for each.