Bug 428718 – <media-gfx/imagemagick-6.7.8.7, <media-gfx/graphicsmagick-1.3.16-r1: Magick_png_malloc() size argument / GraphicsMagick: png_IM_malloc() size argument (CVE-2012-{3437,3438})

• Status: RESOLVED FIXED
• Product: Gentoo Security

[Description taaroa 2012-07-30 22:26:06 UTC]

Tom Lane ([e-mail]) 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.

For more information please see:

https://bugzilla.redhat.com/show_bug.cgi?id=844101
https://bugzilla.redhat.com/show_bug.cgi?id=844105

Reproducible: Always

[Comment 1 Sean Amoss (RETIRED) 2012-07-31 11:15:24 UTC]

Thank you for the report, taaroa.

[Comment 2 Samuli Suominen (RETIRED) 2012-07-31 14:38:18 UTC]

imagemagick-6.7.8.7 has a patch for this issue and is now in Portage, but I don't know about graphicsmagick (yet?)

[Comment 3 Sean Amoss (RETIRED) 2012-07-31 20:52:40 UTC]

(In reply to comment #2)
> imagemagick-6.7.8.7 has a patch for this issue and is now in Portage, but I
> don't know about graphicsmagick (yet?)

Red Hat bug shows that there is an upstream patch:
http://graphicsmagick.hg.sourceforge.net/hgweb/graphicsmagick/graphicsmagick/rev/d6e469d02cd2

[Comment 4 Samuli Suominen (RETIRED) 2012-08-02 15:12:25 UTC]

(In reply to comment #3)
> (In reply to comment #2)
> > imagemagick-6.7.8.7 has a patch for this issue and is now in Portage, but I
> > don't know about graphicsmagick (yet?)
> 
> Red Hat bug shows that there is an upstream patch:
> http://graphicsmagick.hg.sourceforge.net/hgweb/graphicsmagick/graphicsmagick/
> rev/d6e469d02cd2

In Portage as "-1.3.16-r1" with "-libpng14.patch"

Test and stabilize:

=media-gfx/imagemagick-6.7.8.7
=media-gfx/graphicsmagick-1.3.16-r1

[Comment 5 Jeff (JD) Horelick (RETIRED) 2012-08-03 09:08:41 UTC]

x86 stable

[Comment 6 Agostino Sarubbo 2012-08-03 19:06:52 UTC]

amd64 stable

[Comment 7 Jeroen Roovers (RETIRED) 2012-08-04 14:25:52 UTC]

Stable for HPPA.

[Comment 8 GLSAMaker/CVETool Bot 2012-08-08 11:29:51 UTC]

CVE-2012-3438 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2012-3438):
  The Magick_png_malloc function in coders/png.c in GraphicsMagick 6.7.8-6
  does not use the proper variable type for the allocation size, which might
  allow remote attackers to cause a denial of service (crash) via a crafted
  PNG file that triggers incorrect memory allocation.

CVE-2012-3437 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2012-3437):
  The Magick_png_malloc function in coders/png.c in ImageMagick 6.7.8-6 does
  not use the proper variable type for the allocation size, which might allow
  remote attackers to cause a denial of service (crash) via a crafted PNG file
  that triggers incorrect memory allocation.

[Comment 9 Markus Meier 2012-08-12 16:32:39 UTC]

arm stable

[Comment 10 Raúl Porcel (RETIRED) 2012-08-19 14:27:48 UTC]

alpha/ia64/s390/sh/sparc stable

[Comment 11 Brent Baude (RETIRED) 2012-08-28 18:43:44 UTC]

ppc64 done

[Comment 12 Samuli Suominen (RETIRED) 2012-10-04 14:58:09 UTC]

(In reply to comment #11)
> ppc64 done

that wasn't true, but is now:

>>> Creating Manifest for /home/ssuominen/gentoo-x86/media-gfx/graphicsmagick
[ ... snip ... ]
ppc/ppc64 stable wrt #428718

and ppc stable for imagemagick too

last arch done

[Comment 13 Samuli Suominen (RETIRED) 2012-10-04 14:59:47 UTC]

vuln. copies removed from tree too

[Comment 14 Sean Amoss (RETIRED) 2012-10-25 13:12:39 UTC]

Thanks, everyone.

GLSA vote: no.

[Comment 15 Tim Sammut (RETIRED) 2012-12-11 17:36:59 UTC]

GLSA Vote: no, too. Closing noglsa.