SDL_Image 1.2.6 GIF Buffer Overflow

Team Vexillium Security Advisory

* Name      : SDL_Image 1.2.6 and prior GIF handling buffer overflow
* Type      : (Remote) DoS / Code Execution (?)
* Impact    : Low / Medium (?)
* Credits   : gynvael.coldwind//vx
* Discovered: 2007-12-17
* Published : 2008-01-23


* Brief

SDL_Image is an open source library providing image file handling
functionality.
GIF format handling routines suffers from lack of proper buffer
size validating, which makes it vulnerable to a buffer overflow
attack. An attacker could DoS an application using SDL_Image,
or execute arbitrary code (this has not been confirmed, and
is believed to be nontrivial).
Since this is a library, in some cases the attack could be remote.


* Verbose

The problem takes place when a GIF file has invalid LWZ Minimum Code
Size in the Table Based Image Data header. The standard allows the
codes to have maximum size of 12 bits, but this is not checked in
SDL_image.
An attacker could use this for a local or remote buffer overflow
attack that may have denial of service or arbitrary code execution
effect.
 
SDL_image file IMG_gif.c, function ReadImage:

...
    unsigned char c;
...
    if (LWZReadByte(src, TRUE, c) < 0) {
    RWSetMsg("error reading image");
    return NULL;
    }
    /*
    **    If this is an "uninteresting picture" ignore it.
     */
    if (ignore) {
    while (LWZReadByte(src, FALSE, c) >= 0)
        ;
    return NULL;
    }
...

Please note that 'c' value is passed to LZWReadByte without checking
if it is OK with the standard.

Then in function LWZReadByte:

LWZReadByte(SDL_RWops *src, int flag, int input_code_size)
...
    static int table[2][(1 << MAX_LWZ_BITS)];
...
    set_code_size = input_code_size;
...
    clear_code = 1 << set_code_size;
...
    for (i = 0; i < clear_code; ++i) {
        table[0][i] = 0;
        table[1][i] = i;
    }
...

This is the first place that is affected by this issue.


* Proof of concept

DoS proof of concept GIF file:
http://vexillium.org/dl.php?sdlgifdos


* Versions affected and vendor status

Version 1.2.6 and prior are affected.
Vendor was informed and has fixed this issue in 1.2.7.

[Source:Vexillium]

0 comments