Bug 844105 - (CVE-2012-3438) CVE-2012-3438 GraphicsMagick: png_IM_malloc() size argument
CVE-2012-3438 GraphicsMagick: png_IM_malloc() size argument
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=low,public=20120727,reported=2...
: Security
Depends On: 844106 844107
Blocks: 844110
  Show dependency treegraph
 
Reported: 2012-07-28 19:01 EDT by Kurt Seifried
Modified: 2012-10-15 10:29 EDT (History)
3 users (show)

See Also:
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: ---


Attachments (Terms of Use)

  None (edit)
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:

#ifdef PNG_USER_MEM_SUPPORTED
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:

#ifdef PNG_USER_MEM_SUPPORTED
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.

Note You need to log in before you can comment on or make changes to this bug.