CESA-2004-005: gtk+ XPM decoder
CESA-2004-005 - rev 1
http://scary.beasts.org/security/CESA-2004-005.txt
gtk+-2.4.4 XPM image decoder parsing flaws
==========================================
Programs: gtk+, and any programs which use gtk+ to decode XPM files.
For example, Evolution.
Severity: Compromise of account used to browse malicious XPM file.
CAN identifier(s): CAN-2004-0782, CAN-2004-0783
This advisory lists code flaws discovered by inspection of the XPM parser
within the gtk+ code. Specifically, gtk+-2.4.4 was investigated.
Flaw 1. Heap-based overflow in pixbuf_create_from_xpm (io-xpm.c)
CAN-2004-0782
name_buf = g_new (gchar, n_col * (cpp + 1));
colors = g_new (XPMColor, n_col);
Here, n_col is an arbitrary integer value from the XPM. cpp is an integer value
ranging from 1 to 31 from the XPM. By careful choice of values of n_col and
cpp, integer overflow can occur on integer multiplication. This leads to heap
buffers being allocated that cannot hold n_col elements, so a subsequent heap
overflow occurs.
Demo XPM: http://scary.beasts.org/misc/gdk1.xpm
Flaw 2. Subtle stack-based overflow in xpm_extract_color (io-xpm.c)
CAN-2004-0783
gint space = 128;
gchar word[128], color[128], current_color[128];
...
if (color[0] != '\0') {
strcat (color, " ");
[*] space--;
}
strncat (color, word, space);
space -= MIN (space, strlen (word));
Here, an attempt is actually made to prevent overflow of the stack buffers.
However, a logic error means one of the buffers can still be made to overflow.
When "space" reaches 0, "space" can be sent to -1 by the line marked with [*],
if the color string is broken up by whitespace. When "space" is -1, the
strncat() call is effectively morphed to a strcat() call, allowing overflow of
the "color" buffer (probably into the "word" buffer, which may cause a minor
inconvenience to exploitation. Note use of the word "minor" :-)
Demo XPM: http://scary.beasts.org/misc/gdk2.xpm
CESA-2004-005 - rev 1
Chris Evans
chris@xxxxxxxxxxxxxxxx