GHSA-9ccg-6pjw-x645

Описание

Summary

A format string bug vulnerability exists in InterpretImageFilename function where user input is directly passed to FormatLocaleString without proper sanitization. An attacker can overwrite arbitrary memory regions, enabling a wide range of attacks from heap overflow to remote code execution.

Details

root cause

When the InterpretImageFilename function processes a filename beginning with format specifiers such as %d, %o, or %x, the filename string is directly passed as a parameter to the FormatLocaleString function.

Inside FormatLocaleString, the variable argument list is initialized through va_start, after which the format string processing occurs by interpreting the format specifiers and using corresponding values from CPU registers and the call stack as arguments for the formatting operations.

PoC

1. Heap overflow read tested on development container

Processing a malicious filename containing format string specifiers such as %d%n results in corruption of the SplayTree structure stored in the r8 register. The corrupted structure contains invalid pointer values that are later dereferenced by the SplaySplayTree function, causing the function to access unintended memory locations and triggering a heap overflow condition.

2. Shell execution tested on a local environment

https://github.com/user-attachments/assets/00e6a091-8e77-48f0-959e-c05eff69ff94

The exploit achieves remote code execution by leveraging format string vulnerabilities to perform a write-what-where attack. The payload systematically overwrites return addresses on the stack, redirecting program execution to a one-gadget ROP chain that spawns a shell with the current process privileges.

Exploitation Process:

1. Format string payload corrupts stack pointers through positional parameters
2. Multiple 2-byte writes (%hn) progressively overwrite the return address
3. Final payload redirects execution to a one-gadget (0x00007ffff66ebc85)
4. One-gadget executes /bin/sh with inherited process permissions
   

Remote Exploitation Feasibility: While this PoC demonstrates local shell execution with ASLR disabled, remote code execution is achievable in real-world scenarios through brute force attacks. When stack layout conditions are favorable, attackers can perform 1.5-byte return address brute force and 1.5-byte libc base address brute force to gain shell access.

Important: The numeric parameters within the format string payload are environment-dependent and may require modification for different target systems due to variations in memory layout and stack structure.

Note: This demonstrates complete system compromise, as the attacker gains interactive shell access to the target system.

Impact

This format string vulnerability enables attackers to achieve complete system compromise through arbitrary memory read/write operations and remote code execution. Attackers can access sensitive data stored in process memory, overwrite critical system structures, and execute arbitrary code with ImageMagick's privileges.

The vulnerability is particularly dangerous in web applications processing user-uploaded images and automated image processing systems. Successful exploitation can lead to privilege escalation, data exfiltration, and lateral movement within compromised networks.

Suggested Fix

Two potential mitigation approaches:

1. Input Validation: Add format string validation in InterpretImageFilename to reject filenames containing format specifiers (%n, %s, %x, etc.) before passing to FormatLocaleString
2. Safe Parsing: Modify the format string processing to parse and validate each format specifier individually rather than passing the entire user-controlled string directly to FormatLocaleString
   

Credits

Team Daemon Fuzz Hunters

Bug Hunting Master Program, HSpace/Findthegap

Woojin Park @jin-156 1203kids@gmail.com

Hojun Lee @leehohojune leehojune@korea.ac.kr

Youngin Won @amethyst0225 youngin04@korea.ac.kr

Siyeon Han @hanbunny kokosyeon@gmail.com

Additional notes from the ImageMagick team:

On many modern toolchains and OSes, format‑string exploits using %n are already mitigated or blocked by default (e.g., -Wformat-security, _FORTIFY_SOURCE, hardened libc behavior, ASLR/stack canaries). That can make exploitation impractical in typical builds so you might not be vulnerable but it would still be wise to upgrade to the most recent version. We also already provide the following mitigation:

To prevent unintended interpretation of the filename as a format string, users can explicitly disable format string parsing by defining the filename as a literal. This can be done using the following directive:

• In wrappers: filename:literal
• From the command line: -define filename:literal=true