Talos Vulnerability Report

TALOS-2018-0645

October 31, 2018

CVE Number

CVE-2018-3977

Summary

An exploitable code execution vulnerability exists in the XCF image rendering functionality of SDL2_image-2.0.3. A specially crafted XCF image can cause a heap overflow, resulting in code execution. An attacker can display a specially crafted image to trigger this vulnerability.

Tested Versions

Simple DirectMedia Layer SDL2_image 2.0.3

Product URLs

CVSSv3 Score

8.8 - CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

CWE

CWE-122: Heap-based Buffer Overflow

Details

LibSDL is a multi-platform library for easy access to low-level hardware and graphics, providing support for a large amount of video games, software and emulators. The last known count of software using LibSDL (from 2012) was at more than 120. The LibSDL2_Image library is an optional component that deals specifically with parsing and displaying a variety of image file formats, creating a single and uniform API for image processing, regardless of the type.

When parsing and storing an XCF file (the native file type for Gimp), the LibSDL2 library will first create an SDL_Surface object based on the dimensions of the destination object:

Based of these values, the size of the buffer that stores the resulting picture data after parsing SDL_Surface->pixels is allocated to a size corresponding to the data of the final image. The resulting allocation is then calculated with the following code:

Each XCF image consists of a set of layers that get displayed on top of each other. Each of these layers consists of an XCF_hierarchy, which defines a set of XCF_levels inside of the file, which each in turn define a set of tiles that actually define the raw pixel data that is written to the surface->pixels buffer from above.

For each tile, in each XCF_level, inside each layer (three nested loops), we end up writing to the destination buffer at a given offset corresponding to the location of the tile. To clarify:

At [1], we see that we’re going to keep writing to the destination surface->pixels as long as we have more level->tile_file_offsets, which is an array completely under an attacker’s control. When deciding the destination of the formatted image data, the pointer is calculated at [2], as an offset from the surface->pixel buffer, which is affected by both y and tx. At [3], we can see that tx will keep increasing as long as it is less than the level->width and if there are more level->tile_file_offsets, which are also under attacker control.

Thus, the image can describe an arbitrary amount of tiles within the XCF_layer, which, since there’s no checking or correspondence of the layer’s size to the destination surface’s size, allow an attacker to overwrite an arbitrary amount of data on the heap, potentially leading to code execution.