Bug 844101 (CVE-2012-3437)

Summary: CVE-2012-3437 ImageMagick: Magick_png_malloc() size argument
Product: [Other] Security Response Reporter: Kurt Seifried <kseifried>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: NEW --- QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: kem, mfisher, mmcgrath, nmurray, pahan
Target Milestone: ---Keywords: Reopened, 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/ImageMagick=affected,rhel-5/ImageMagick=defer,rhel-6/ImageMagick=defer,openshift-1/ImageMagick=affected
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-12-14 14:22:55 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On: 844103, 844104, 1165396    
Bug Blocks: 844110    
Description Flags
Patch for CVE-2012-3437 from ImageMagick SVN none

Description Kurt Seifried 2012-07-28 18:52:20 EDT
Tom Lane (tgl@redhat.com) found an issue in ImageMagick. 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));

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 18:54:13 EDT
Created ImageMagick tracking bugs for this issue

Affects: fedora-all [bug 844103]
Comment 3 Kurt Seifried 2012-07-28 18:57:47 EDT
Created attachment 600950 [details]
Patch for CVE-2012-3437 from ImageMagick SVN
Comment 5 Huzaifa S. Sidhpurwala 2012-07-30 02:28:36 EDT

This issue affects the version of ImageMagick, as shipped with Red Hat Enterprise Linux 5 and 6. The Red Hat Security Response Team has rated this issue as having low security impact. A future update may address this issue.
Comment 6 Pavel Alexeev 2012-08-11 15:12:13 EDT
(In reply to comment #3)
> Created attachment 600950 [details]
> Patch for CVE-2012-3437 from ImageMagick SVN

If I right understand it is reverse patch, forward should be http://trac.imagemagick.org/changeset/8733/ImageMagick/trunk/coders/png.c ?
Comment 7 Fedora Update System 2012-08-27 18:54:00 EDT
ImageMagick- has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 8 Fedora Update System 2012-08-27 18:59:25 EDT
ImageMagick- has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 9 Rob Millner 2012-12-10 20:28:59 EST
OpenShift does not grant sufficient resources to any customer application for it to hold a 4GB PNG file in the filesystem or malloc that much memory.  I'm deferring Bug 844104 for a fixed package in RHEL 6.