---

archetype: memory-unsafe-parsers

primary_gate_families: [1]

---

# Archetype - Memory-Unsafe Parsers (Fuzz + ASan → Corruption → RCE)

Targets: image codecs (libwebp, libjpeg-turbo, libpng, libtiff, OpenEXR, libheif, libavif),

archive libs (libarchive, zlib/zstd/lz4, minizip, 7-Zip), font shapers (FreeType, HarfBuzz),

serialization (protobuf C++, flatbuffers, msgpack-c, CBOR, ASN.1/OpenSSL), media demuxers (FFmpeg),

document/XML (libxml2, expat), and any C/C++ library that turns a byte stream into a structure. The

thesis: these are **pure functions from attacker bytes to memory operations**, written in C/C++,

embedded *everywhere* (a libwebp bug is in every browser and Electron app), and they are the ideal

target for the only oracle that never lies - **a sanitizer crash**. This is the purest

[[../00-doctrine/SEVERITY-GATE#family-1-remote-code-execution-the-crown|Family 1]] archetype, and it

is the engine room behind [[ml-model-loaders]] (model files are just another parser input).

See: [[ml-model-loaders]] (GGUF/safetensors/ONNX parsers - same mechanics, ML inputs). Tooling:

`compile_harness`, `fuzz_start`/`fuzz_status`/`fuzz_get_crashes`, `boofuzz_session`, `triage_crash`,

`angr_analyze`, `ghidra_decompile`, `r2_analyze`, `concolic_trace`, `run_klee`, `z3_solve`.

---

## Principals & trust boundaries

- **Principals:** the content author (anyone who can hand the app a file/stream - a webpage serving an

  image, an email attachment, a document, a network packet), the **parser library**, the host process.

- **Core boundary:** *attacker bytes → parse routine → memory operation*. There is no user, no auth,

  no session - just a format and a function. The "trust input" is the entire file format spec, and

  every length/count/offset/index field in it is attacker-controlled.

**Boundary map template:**

```

principals:        content-author(untrusted bytes) → parser library → host process

trust inputs:      every header field, chunk length, element count, dimension, offset, index,

                   compression ratio, and nested-structure depth in the format

enforcement pts:   bounds checks before memcpy/index, integer-overflow checks on size math,

                   recursion/iteration limits, allocation-size sanity, the "is this offset inside

                   the buffer" validations

cross-boundary

sinks:             memcpy/memmove/memset with file-derived length ; array index from file field ;

                   malloc(a*b) where a*b can overflow ; alloca/VLA from file size ; pointer arithmetic

                   base+offset ; type/enum field indexing a function/size table ; recursive parse

confusion

hypotheses:        "chunk_length is trusted before checking remaining buffer";

                   "width*height*bpp overflows size_t before the alloc";

                   "a negative/huge offset isn't validated against buffer bounds";

                   "the type byte indexes a handler table without a range check";

                   "decompressed size is trusted from the header"

```

---

## Kill chains (all land on Family 1)

### KC-1 - Integer overflow in size math → undersized alloc → heap overflow

The single most productive bug class. A `width * height * channels`, `count * elem_size`, or

`n0*n1*n2` multiply overflows `size_t`/`int`, the wrapped-small value is passed to `malloc`, then the

real (large) data is `memcpy`'d in → heap overflow with attacker bytes.

- **CVE class to cite:** the libwebp `BuildHuffmanTable` overflow (CVE-2023-4863, the "everything that

  embeds Chromium" bug), countless libtiff/OpenEXR/FFmpeg integer-overflow heap overflows.

- **Sinks to CPG-trace:** every `malloc`/`calloc`/`realloc`/`alloca` whose size arg is a *product* or

  *sum* of file-derived values; pair each with the subsequent `memcpy`/write loop.

### KC-2 - Missing bounds check before memcpy / OOB index

A chunk-length, offset, or array-count field is *trusted* and used to copy/index before validating it

against the remaining buffer. → OOB read (info leak / DoS) or OOB write (corruption).

- **Sinks:** `memcpy(dst, src, file_len)`, `buf[file_index]`, `base + file_offset` deref; the classic

  "read `n`, then loop `n` times reading more without checking we have `n` left".

### KC-3 - Type/enum confusion → wrong-size handler / OOB table index

A type/format byte selects a handler or a per-type size from a table; an out-of-range or unexpected

value indexes the table OOB or invokes a handler that mis-sizes the data. (ggml `ggml_type` table,

image color-type dispatch, ASN.1 tag handling.)

### KC-4 - Decompression / recursion bombs into corruption (not just DoS)

A header-declared decompressed size is trusted for an alloc while the actual stream writes more

(or a nested-structure depth has no limit and overflows the stack). **Discipline:** a pure

zip-bomb/OOM is DoS → cleared-axes, **not** Family 1. Only a *corruption* (controlled OOB write)

counts. Don't dress DoS as RCE.

---

## The dynamic oracle - this is the whole archetype

The oracle is **non-negotiable and unambiguous**: a sanitizer crash with a *controlled* fault.

1. `clone_repo` the freshest in-scope parser; pin the commit. Prefer a library that just merged a new

   format/feature (unfuzzed code - see [[../06-methods/NOVELTY-DOCTRINE]]).

2. `compile_harness` with `-fsanitize=address,undefined` (add MSan for uninit-read hunts). If the

   project has an OSS-Fuzz harness, **re-run it on the new commit** - OSS-Fuzz fuzzed yesterday's code,

   not today's PR.

3. `fuzz_start` (libFuzzer/AFL++) with the parse entry point as the target and **valid sample files as

   the seed corpus** (coverage-guided needs good seeds). For structured formats, a `boofuzz_session`

   or a format-aware mutator beats dumb flips.

4. `fuzz_get_crashes` → `triage_crash`. **Classify the fault:**

   - heap/stack **write** to attacker data, or **PC control** → strong Family 1 candidate.

   - OOB **read** of secrets → Family 7 (info leak) candidate.

   - null-deref / divide-by-zero / assertion / OOM → **DoS → DISPROVEN for RCE**, cleared-axes.

5. For a write/PC-control crash, escalate exploitability: `angr_analyze` / `concolic_trace` /

   `z3_solve` to show attacker control of the corrupted pointer/size; `ghidra_decompile`/`r2_analyze`

   to confirm the primitive. The minimized crashing file is the REPLICA_CONFIRMED artifact.

6. The *finding* claim scales with what you proved: "controlled heap overflow, PC control demonstrated"

   is Family 1; "OOB read crash, exploitability unproven" stays SOURCE_CONFIRMED until you show the

   write/control. Do not over-claim a read-crash as RCE.

---

## BORING traps - do NOT spend time here

- **Calling every crash "RCE".** A null-deref or an `abort()` is a **DoS**, not RCE, and DoS is not a

  [[../00-doctrine/SEVERITY-GATE|gate]] family. Triage honestly; most fuzz crashes are DoS.

- **OOM / zip-bomb / "huge allocation".** Resource exhaustion ≠ memory corruption. Cleared-axes.

- **Re-finding a known CVE in an old library version.** Sibling-CVE / patch-status observation. Fuzz

  **fresh** code, new formats, new ports.

- **Unreachable code paths.** A crash in a parse path the real application never invokes (a disabled

  feature, a non-default codec) is low-value until you show a real consumer reaches it.

- **A crash you can't reproduce on a clean rebuild.** Flaky ≠ confirmed; downgrade per

  [[../00-doctrine/OPERATING-CORE#3-proof-labels-the-four-states-a-candidate-can-be-in|proof labels]].

- **Stopping at "it crashes".** A crash is the *start* of exploitability analysis, not the end. For

  the RCE claim, show attacker control of the corruption.