Bug 143533 – media-gfx/imagemagick: heap and stack buffer overflow (CVE-2006-374{3|4})

• Product: Gentoo Security
• Status: RESOLVED FIXED

[Description Sune Kloppenborg Jeppesen (RETIRED) 2006-08-10 23:31:10 UTC]

Hi there, a quick look at two of the codecs from ImageMagick 6.2.8
revealed some missing bounds checks.

The sun bitmap decoder is vulnerable to multiple heap buffer overflows
due to the absence of bounds checking and unchecked arithmetic
operations on attacker supplied values. The DecodeImage() routine from
sun.c, line ~170 performs absolutely no bounds checking on the inner
rle decoding loop, allowing an attacker to use a runlength encoded
payload to overflow the destination buffer.

ReadSUNImage() from sun.c, line ~206, performs no range checking on
attacker supplied values before using them in arithmetic operations
used to allocate memory for decoded image data. A particularly
favourable heap layout (callbacks/function pointers easily within
reach) results in a trivially exploitable heap overflow.

line 299:
  bytes_per_line=2*(sun_info.width*sun_info.depth+15)/16;
  sun_pixels=(unsigned char *) AcquireMagickMemory(bytes_per_line*height);

line ~382:
  sun_data=(unsigned char *) AcquireMagickMemory((size_t)
sun_info.length*sizeof(*sun_data));

The xcf "GIMP Image" decoder suffers from multiple buffer overflows,
including a heap and a stack overflow. Both of these are exploitable
to execute arbitrary code by supplying an malformed image. The stack
buffer overflow is in the PROP_USER_UNIT handling, line ~1097 of
xcf.c, where a fixed 1000 byte stack buffer receives a string of
length specified by an attacker via the ReadBlobStringWithLongSize()
function. The same non-bounds-checking function is used to read the
Layer Name onto a heap buffer. This vulnerability also looks
exploitable.

Possible fix and testcases attached.

I'll suggest Tuesday 22nd of August as an embargo data, if there are
no objections I'll forward these details to the upstream maintainers.

Please credit "Tavis Ormandy, Google Security Team" in any advisories
relating to these issues.

Thanks, Tavis.

[Comment 1 Sune Kloppenborg Jeppesen (RETIRED) 2006-08-10 23:32:07 UTC]

Created attachment 93968 [details, diff]
imagemagick-6.2.8-goo-sec.diff

[Comment 2 Sune Kloppenborg Jeppesen (RETIRED) 2006-08-10 23:32:23 UTC]

Created attachment 93969 [details]
imagemagick-sun-raster-demo.bmp

[Comment 3 Sune Kloppenborg Jeppesen (RETIRED) 2006-08-10 23:32:35 UTC]

Created attachment 93970 [details]
imagemagick-xcf-codec-demo.jpg

[Comment 4 Sune Kloppenborg Jeppesen (RETIRED) 2006-08-23 08:45:58 UTC]

Karol sorry for the late CC on this one. It should be public but I haven't seen any announcements yet.

[Comment 5 Raphael Marichez (Falco) (RETIRED) 2006-08-31 08:18:56 UTC]

Public since a while. This bug was opened before #144854 so i mark the other one as dup of this one.

Hi Karol, please advise :)

[Comment 6 Raphael Marichez (Falco) (RETIRED) 2006-08-31 08:19:06 UTC]

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

[Comment 7 Sune Kloppenborg Jeppesen (RETIRED) 2006-09-05 06:26:45 UTC]

sekretarz, any news on this one?

[Comment 8 Sune Kloppenborg Jeppesen (RETIRED) 2006-09-05 10:28:53 UTC]

Pulling in graphics herd for advise.

[Comment 9 Sune Kloppenborg Jeppesen (RETIRED) 2006-09-13 23:32:24 UTC]

-dev mailed for assistance.

[Comment 10 SpanKY 2006-09-14 00:24:32 UTC]

6.2.9.5 now in portage

[Comment 11 Sune Kloppenborg Jeppesen (RETIRED) 2006-09-14 03:15:06 UTC]

Handling stable marking of 6.2.9.5 on bug #144091

[Comment 12 Sune Kloppenborg Jeppesen (RETIRED) 2006-09-26 08:40:49 UTC]

GLSA 200609-14