Critical ImageMagick Flaw Lets Attackers Execute Code Through File Name Exploits

A severe stack buffer overflow vulnerability has been identified in ImageMagick’s image.c component, affecting versions prior to 7.1.2-0 and 6.9.13-26.

The vulnerability, tracked as CWE-124: Buffer Underwrite, was discovered in the InterpretImageFilename() function and can be triggered through malicious filename templates containing consecutive %d format specifiers.

Security researchers have successfully reproduced the issue using AddressSanitizer, confirming that the flaw allows memory writes to occur before the beginning of allocated stack buffers, potentially leading to arbitrary code execution or system crashes.

Vulnerability Discovery and Impact Assessment

The security vulnerability was published as GHSA-qh3h-j545-h8c9 by urban-warrior, highlighting a critical flaw in ImageMagick’s magick mogrify command processing.

The issue manifests when users specify multiple consecutive %d format specifiers in filename templates, causing internal pointer arithmetic to generate addresses below the stack buffer’s beginning.

This results in a dangerous condition where vsnprintf() writes to unauthorized memory locations, triggering a stack overflow condition.

The affected component, MagickCore/image.c, specifically within the InterpretImageFilename() function, processes format specifiers incorrectly due to flawed offset correction mechanisms.

When processing consecutive format specifiers like %d%d, the system’s cumulative offset calculation using offset += (4 - field_width) creates excessive increments that exceed the relative position within the template string.

This design flaw causes the write destination address to point before the legitimate filename buffer, resulting in buffer underwrite conditions that compromise system stability and security.

Technical Analysis and Reproduction Steps

Security researchers successfully reproduced the vulnerability on Ubuntu 22.04 LTS using a 64-bit architecture with gcc 11.4.0 and AddressSanitizer enabled.

The reproduction process involves cloning the ImageMagick source code from the affected branch 7.1.1-47, compiling with specific security flags, and executing the problematic command:

bashgit clone --depth 1 --branch 7.1.1-47 https://github.com/ImageMagick/ImageMagick.git
cd ImageMagick-7.1.1
CFLAGS="-g -O0 -fsanitize=address -fno-omit-frame-pointer" ./configure --enable-maintainer-mode
make -j$(nproc) && make install
./utilities/magick mogrify %d%d

The AddressSanitizer output reveals critical details about the memory corruption, showing a stack-buffer-overflow at address 0x7ffda834caae with a write operation of size 2.

The vulnerability occurs in the __interceptor_vsnprintf function, propagating through FormatLocaleStringList, FormatLocaleString, and ultimately InterpretImageFilename.

The technical root cause lies in the static offset correction mechanism that fails to account for varying format specifier lengths, creating negative pointer arithmetic when consecutive specifiers are processed.

Proposed Fix and Security Recommendations

The development team has identified a comprehensive solution that addresses the fundamental design flaw in offset calculation.

The proposed fix introduces dynamic offset correction based on actual template structure rather than static constants:

cwritten = FormatLocaleString(filename+(p-format-offset), (size_t)
    (MagickPathExtent-(p-format-offset)), p, value);
if (written <= 0 || written > (MagickPathExtent - (p - format - offset)))
    return 0;
offset += (ssize_t)((q - p) - written);

This solution implements several critical improvements: dynamic offset calculation using the difference between template description length (q - p) and actual output bytes written, comprehensive range checking to detect vsnprintf() failures and excessive writes, and elimination of the problematic static constant-based correction mechanism.

Users are strongly advised to upgrade to ImageMagick 7.1.2-0 or 6.9.13-26 immediately to mitigate this security risk.

Organizations should implement input validation for filename templates and consider restricting format specifier usage in user-controlled contexts until patches are applied.

Find this Story Interesting! Follow us on Google News, LinkedIn, and X to Get More Instant updates