Bug 844101 - (CVE-2012-3437) CVE-2012-3437 ImageMagick: Magick_png_malloc() size argument
CVE-2012-3437 ImageMagick: Magick_png_malloc() size argument
Status: CLOSED WONTFIX
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...
: Reopened, Security
Depends On: 844103 844104 1165396
Blocks: 844110
  Show dependency treegraph
 
Reported: 2012-07-28 18:52 EDT by Kurt Seifried
Modified: 2016-06-10 17:36 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-06-10 17:36:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch for CVE-2012-3437 from ImageMagick SVN (2.15 KB, patch)
2012-07-28 18:57 EDT, Kurt Seifried
no flags Details | Diff

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

#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));
}

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 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-6.7.5.6-4.fc17 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-6.7.0.10-6.fc16 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.
Comment 11 Vincent Danen 2016-06-10 17:36:29 EDT
Statement:

Red Hat Product Security has rated this issue as having Low security impact. This issue is not currently planned to be addressed in future updates. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.

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