| Titolo | Matthias-Wandel jhead v3.3 (commit 5007491, 3.08-66-g5007491) heap-buffer-overflow (Get32u) |
|---|
| Descrizione | Affected Versions
jhead commit 5007491 (3.08-66-g5007491): reproduced with AddressSanitizer. This is the repository HEAD at the time of the report.
The version is annotated as v3.3 (commit 5007491, 3.08-66-g5007491) in the public report.
As of the submission material date (2026-08-04), no upstream fix commit exists. No fixed release is identified. The status should be updated once the maintainer merges a fix.
Classification
Attack type: Local
Attack complexity: Low
Privileges required: None
User interaction: Required
Exploit availability: Public proof-of-concept
Proven impact: Application crash and loss of availability (out-of-bounds read)
Suggested severity: Medium
CVSS 3.1 score: 5.5
CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
Technical Description
jhead is affected by a heap buffer out-of-bounds read while parsing the GPS sub-directory of a crafted WebP file's EXIF chunk. In ProcessGpsInfo (gpsinfo.c:144), GPS latitude/longitude rational denominators are read with den = Get32s(ValuePtr+4+a*ComponentSize) without validating that the value pointer plus the read size lies within the valid EXIF buffer range [OffsetBase, OffsetBase+ExifLength).
A malformed EXIF GPS sub-directory allows an attacker-controlled ValuePtr to land past the allocated buffer. Get32s (exif.c:341) then reads 4 bytes past the end of the region, producing a 4-byte out-of-bounds read. AddressSanitizer reports the heap-buffer-overflow and aborts jhead, causing denial of service when a user or automated image-processing workflow parses the malicious WebP file. No special command-line flags are required to trigger the bug.
The public report notes this may be an incomplete fix for jhead issue #62. The proven impact is an out-of-bounds read and process crash. The submission does not assert demonstrated confidentiality disclosure, code execution, or privilege escalation.
Proof of Concept
PoC archive: issue-99_poc.zip PoC URL: https://github.com/user-attachments/files/30397094/poc.zip
The PoC is a 4208-byte malformed WebP file with a crafted EXIF GPS sub-directory that causes ValuePtr to point past the buffer boundary.
Command:
# Build with AddressSanitizer
CC=afl-clang-fast CFLAGS="-fsanitize=address" make
# Trigger the crash (no special flags needed)
ASAN_OPTIONS="detect_leaks=0:halt_on_error=1" ./jhead poc.bin
Observed sanitizer result:
==1658674==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61e000000baa
READ of size 1 at 0x61e000000baa thread T0
#0 in Get32s exif.c:341
#1 in ProcessGpsInfo gpsinfo.c:144
#2 in ProcessExifDir exif.c:892
#3 in process_EXIF exif.c:1063
#4 in ReadWebpSections webpfile.c:129
#5 in ReadImgFile imgfile.c:76
#6 in ProcessFile jhead.c:491
#7 in main jhead.c:1150
0x61e000000baa is located 4 bytes to the right of 2854-byte region [0x61e000000080,0x61e000000ba6)
SUMMARY: AddressSanitizer: heap-buffer-overflow exif.c:341 in Get32s
==1658674==ABORTING
Root Cause
ProcessGpsInfo reads GPS rational values through a ValuePtr derived from EXIF directory entry offsets, but does not verify that ValuePtr + read_size stays within [OffsetBase, OffsetBase+ExifLength). The main directory bounds check does not cover this GPS value-access path, so a crafted GPS sub-directory can position ValuePtr beyond the buffer and trigger a 4-byte out-of-bounds read inside Get32s.
Countermeasure
As of 2026-08-04 the upstream issue is still open and no fix commit is available. Environments that cannot wait for an upstream fix should:
Avoid processing untrusted WebP/EXIF files with the affected jhead build.
Run jhead in a sandboxed, low-privilege environment with resource limits.
Apply process timeouts, crash isolation, and failed-file quarantine for automated pipelines.
Pre-validate or transcode inputs with a trusted image library before invoking jhead.
Suggested fix direction: validate ValuePtr + read_size <= OffsetBase + ExifLength before any EXIF value read in ProcessGpsInfo and all other EXIF value-access paths, so that the GPS sub-directory cannot bypass the main directory range check.
This entry should be updated with the fix commit and fixed release once the maintainer merges a patch. |
|---|
| Fonte | ⚠️ https://github.com/Matthias-Wandel/jhead/issues/99 |
|---|
| Utente | fczhang (UID 97720) |
|---|
| Sottomissione | 04/08/2026 15:51 (1 mese fa) |
|---|
| Moderazione | 13/09/2026 06:48 (1 month later) |
|---|
| Stato | Accettato |
|---|
| Voce VulDB | 403215 [Matthias-Wandel jhead fino a 3.3 WebP EXIF gpsinfo.c ProcessGpsInfo TAG_GPS_LAT/TAG_GPS_LONG buffer overflow] |
|---|
| Punti | 20 |
|---|