The missing check that turns a file field into a heap overflow
A five-minute investigation into how one attacker-controlled number crosses the codebase and reaches a dangerous copy.
Projectatlas-image-parser
Affected versionv3.4.1 (vulnerable)
ImpactA malicious image can make the parser write beyond the end of a heap buffer.
01The short version
The file says how many bytes to copy. The program believes it. No one checks whether that number fits the destination.
That one sentence is the whole investigation. Now let’s prove it—one hop at a time.
The investigation
Follow the bug.
01/ 04
01 · The entry point
The file gets to choose a number
An image header contains a 32-bit payload length. It looks like ordinary metadata, but it is attacker-controlled the moment the parser opens an untrusted file.
✦SOURCE FOUND · payload_len ← image header
uint32_t payload_len = read_u32(file);Your turn
Where does payload_len come from?
The fix
Make the safety rule explicit.
The fix makes the safety relationship explicit before the copy runs.
vulnerable
memcpy(dst, payload, payload_len);
patched
if (payload_len > dst_capacity) return ATLAS_ERR_SIZE; memcpy(dst, payload, payload_len);
Keep going
Try Lachesis Want the original evidence?
Read the references behind this investigation, or use Lachesis to ask the same kind of questions about your own codebase.