there is a is an integer overflow in Gimp when loading PSD files. Affected product: Gimp Affected version: 2.2.15. Other versions may also be affected CVE: CVE-2007-2949 SAID: 25677 (http://secunia.com/advisories/25677/) Credit: Stefan Cornelius, Secunia Research Disclosure date: Preliminary date set to Wed 27th June, 2007. -- Background -- "GIMP is the GNU Image Manipulation Program. It is a freely distributed piece of software for such tasks as photo retouching, image composition and image authoring. It works on many operating systems." PSD is an image file format originally used by Adobe Photoshop. File format specifications can be found here: http://www.fileformat.info/format/psd/spec/index.htm -- Analysis -- The vulnerability is caused due to an integer overflow within the function "seek_to_and_unpack_pixeldata()" in plug-ins/common/psd.c. The file format documentation used during research states that valid width and height values are between 1 and 30000. However, Gimp doesn't check that and uses the values in an insecure arithmetic function to determine the amount of memory to allocate, which may be exploited to cause a heap-based buffer overflow. seek_to_and_unpack_pixeldata(FILE* fd, gint layeri, gint channeli) { int width, height; [1] guchar *tmpline; gint compression; guint32 offset = 0; PSDchannel *channel = &psd_image.layer[layeri].channel[channeli]; fsetpos(fd, &channel->fpos); compression = getgshort(fd, "layer channel compression type"); offset+=2; width = channel->width; [2] height = channel->height; [2] IFDBG { printf("\t\t\tLayer (%d) Channel (%d:%d) Compression: %d (%s)\n", layeri, channeli, channel->type, compression, compression==0?"raw":(compression==1?"RLE":"*UNKNOWN!*")); fflush(stdout); } channel->data = g_malloc (width * height); [3] tmpline = g_malloc(width + 1); switch (compression) { case 0: /* raw data */ { gint linei; for (linei = 0; linei < height; linei++) { xfread(fd, channel->data + linei * width, width, "raw channel line"); [4] offset += width; } #if 0 /* Pad raw data to multiple of 2? */ if ((height * width) & 1) { getguchar(fd, "raw channel padding"); offset++; } #endif } break; case 1: /* RLE, one row at a time, padded to an even width */ { ---- [1] define variables width and height [2] assign unchecked values to the variables [3] multiply width and height, use result to allocate memory. If width and height are certain large values, this will overflow and an insufficient amount of memory is allocated. [4] Load data from file and copy it into the buffer. (In this case for the uncompressed format - RLE encoded files may also be affected). -- Exploitation -- The vulnerability can be exploited to cause a heap-based buffer overflow by e.g. tricking a user into opening a specially crafted PSD file with certain width and height information. Successful exploitation may allow execution of arbitrary code. Credits should be given to: Stefan Cornelius, Secunia Research.
Friendly reminder: waiting for upstream and please don't commit anything before the 27th.
has this been delayed? didn't see a public advisory anywhere.
It's public now. http://secunia.com/advisories/25677/
*** Bug 184141 has been marked as a duplicate of this bug. ***
gimp 2.2.16 added, archs, please mark stable. security, please make this bug public. A problem is with 2.3.x. Upstream hasn't released an update and it seems that it's more than just one integer overflow (and they aren't documented properly). I think we can just wait for a new 2.3.x-release.
ppc64 stable
Stable for HPPA.
x86 stable
alpha/ia64 stable
sparc stable.
amd64 stable
ppc stable, ready for GLSA.
*** Bug 184782 has been marked as a duplicate of this bug. ***
GLSA 200707-09
mips stable.