CWE-476: NULL Pointer Dereference in XPM Image Parser (ImLib2)

[michaelknap]

I identified a null pointer dereference vulnerability in the XPM image parser, which is part of the imlib2 library used by the feh. This issue occurs under certain conditions when handling doctored XPM files with manipulated header data. While I understand that the vulnerability specifically resides within imlib2 and not feh itself, I was unable to find contact details for the imlib2 maintainer(s). Given feh's reliance on this library, it seemed appropriate to bring this matter to the attention of the feh developers.

Affected Component
imlib2-1.12.1

The vulnerability resides in the image loading function, specifically in the portion of code responsible for handling XPM images (_load function).

Conditions for Triggering the Vulnerability

• The vulnerability is triggered by XPM files with header values that do not accurately represent the underlying image data.
• Specifically, manipulating the number of colors (ncolors) to values higher than what is actually provided in the color table can lead to a scenario where the color map (cmap) is not correctly initialized.
• Additionally, there is a condition where the im->data array is accessed for populating image data, assuming that cmap is valid and not NULL.
• Condition where image file is missing color table and pixel data (essentially just file with header) will also trigger the bug.

Technical Details
Two separate GDB outputs indicate scenarios where the application attempts to dereference NULL pointers during image processing:

First Scenario:

• The application crashes while trying to access im->data[count] assuming cmap is not NULL.
• Registers and stack traces indicate that rcx is used to reference memory (mov DWORD PTR [rcx], esi), but rcx contains 0x0, leading to a segmentation fault.

Second Scenario:

• Similar to the first, but with slightly different register values, again attempting to access memory via a NULL pointer.
• Both scenarios occur within the same line of code (im->data[count] = cmap[0].pixel;), suggesting a common failure pattern related to inadequate validation of the XPM header and improper handling of dynamically allocated memory for cmap and image data.

Impact
Exploiting this vulnerability could lead to denial of service (DoS) by causing the application to crash. There is no direct indication of arbitrary code execution, but the dereferencing of null pointers is a critical issue that undermines the stability of the application.

Steps to Reproduce

• Create a malformed XPM file with a header that specifies more colors than are actually defined in the color table.
• Attempt to load this image using the affected application.
• Observe that the application crashes while processing the image.

Recommended Mitigation Strategies
Implement rigorous validation of XPM header data before proceeding with memory allocations and data processing.
Ensure that cmap and im->data are properly allocated and initialized before use. If allocation fails, gracefully handle the error without proceeding to dereference potentially null pointers.
Consider adding additional sanity checks before accessing arrays based on external input to prevent out-of-bounds or null pointer access.

We can cause both structures to be NULL.

pocs.zip

[michaelknap]

I found the imlib2 git and raised the issue there:
https://git.enlightenment.org/old/legacy-imlib2/issues/22
It has been addressed, closing this issue.