Bugzilla Bug 69070

Subject:

GD Graphics Library integer overflow leading to heap overflow.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Product Description:

An ANSI C library for the dynamic creation of images. GD creates PNG, JPEG and
GIF images, among other formats.  It is the library used by PHP to manipulate
images.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Vulnerable:

Only the latest version was tested, gd-2.0.28.  I would venture a guess that old
versions are vulnerable as well, as I found no checking anywhere for the type of
bugs found.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Summary:

There is an integer overflow when allocating memory in the routine that handles
loading PNG image files.  This later leads to heap data structures being
overwritten.  If an attacker tricked a user into loading a malicious PNG image,
they could leverage this into executing arbitrary code in the context of the
user opening image.  Many programs use GD, such as ImageMagick, and more
importantly it is also the image library used for PHP, and there is a Perl
module as well.  One possibile target would be PHP driven photo websites that
let users upload images.  Some of them will resize/compress the image when the
user uploads them.  If this is done using GD, this could be used to execute code
on the server.  There is a mitigating factor, in order to reach the vulnerable
code, a large amount of memory needs to be allocated.  My 128MB p2 crapped out
one allocation before it reached the overflow.  However, I think on a newer box
with lots of memory and swap space, that won't be a problem.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Details:

The vulnerable code occurs in the file gd_png.c, in the function
gdImageCreateFromPngCtx(), which is called by gdImageCreateFromPng().  The
function is used to load an image file into GD data structures.  The problem
occurs when allocating memory for the image rows, line 314 or so ( I added some
comments so line number might be off).  Two user supplied values are multiplied
together (rowbytes * height), and used to allocate memory for an array of
pointers.  This pointer array is then passed to the png_read_image() function,
which belongs to the libPNG library.  In that function, the pointers are passed
to the png_read_row() function.  The data for the rows is decompressed using
zLib function inflate(), and then passed to the png_combine_row() function,
where the deflated data is memcpy()'d into the heap buffer.  Exploitation would
require using zLib functions to compress the payload.  Successful exploitation
would lead to executing arbitrary code.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Vendor:

I spoke with author about a month ago, he told me that updates would be out
within a couple weeks.  I'm assuming they are.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Exploit:

The start of my exploit is attached.  I didn't pursue further b/c my box sucks
ass, and doesn't have enough memory/swap.

I don't see any new version or fix for this issue anywhere.

I sent an email upstream regarding this issue, and awaiting a response.

Reply from upstream:

"2.0.29 will be out in the next few days. I apologize for the delay.
(The bug, for what it's worth, is quite challenging to exploit.)"

depending on what the exploit is, php may be at risk also

*** Bug 69156 has been marked as a duplicate of this bug. ***

2.0.30 is out at boutell.com.
vapier: please bump

looking at php-5.0.2's ext/gd/libgd/gd_png.c, i would venture to say that the
exploit exists there too

sample from the gd patch:
--- gd-2.0.28/gd_png.c  2004-05-24 10:42:18.000000000 -0400
+++ gd-2.0.30/gd_png.c  2004-10-28 14:09:52.000000000 -0400
@@ -312,12 +312,21 @@

   /* allocate space for the PNG image data */
   rowbytes = png_get_rowbytes (png_ptr, info_ptr);
+  if (overflow2(rowbytes, height)) {
+    png_destroy_read_struct (&png_ptr, &info_ptr, NULL);
+    return NULL;
+  }
   if ((image_data = (png_bytep) gdMalloc (rowbytes * height)) == NULL)
     {

snippet from php-5.0.2's gd_png.c:
    /* allocate space for the PNG image data */
    rowbytes = png_get_rowbytes(png_ptr, info_ptr);
    image_data = (png_bytep) safe_emalloc(rowbytes, height, 0);

i'd suggest we fork php off to a sep bug so as to not hold back gd-2.0.30

i marked stable for the arches i maintain ... here's the current KEYWORDS:
KEYWORDS="~alpha ~amd64 arm hppa ia64 ~mips ~ppc ~ppc64 s390 ~sparc x86"

Arches, please mark stable

Stable on ppc.

Stable on alpha.

Stable on sparc

ok, 1.8.4 also has this problem ... i forward ported a patch
(1.8.4-png-overflows.patch) and added to cvs ...

i contacted upstream to see what their take is on 1.x ... if they dont plan on
updating their 1.8.4, i might just remove it from the tree

amd64, ppc64, please mark stable

*** Bug 69850 has been marked as a duplicate of this bug. ***

That would be CAN-2004-0990

stable amd64

stable on ppc64

i e-mailed upstream about two bugs ...
(1) he released 2.0.32 in response to a compile failure
(2) he removed 1.x completely :)  i'll do the same for us

Ack! Please return 1.8.4 to the tree - otherwise www-apps/nut-2.0.0 breaks!

It seems that the www-apps/nut ebuild breaks, but if you change the ebuild it
will build against gd-2. I'll enter a bug for nut to make the ebuild work with
gd-2.

GLSA 200411-08
mips: mark stable to benefit from GLSA

yeah, gd-1.x isnt coming back ;)

nut will have to be fixed/removed

Stable on mips.

Created an attachment (id=43704) [edit]
gd-1.8.4-security.patch

For those of you that need gd-1.8.4 still this patch resolves CAN-2004-0941 and
CAN-2004-0990