Finding CVE-2020-1321: Fuzzing Microsoft Office's 3D Model Parser

The fuzzer is a custom build I wrote on top of Domato, Google Project Zero's grammar fuzzer. Domato's Grammar engine is unmodified. The interesting work is in the glTF-specific grammars, the JSON template, and the Office harness on top.

The per-section grammars were authored from the Khronos glTF 2.0 JSON Schema files. There is one .schema per top-level glTF object: accessor, bufferView, mesh, node, animation.channel, animation.sampler, material, texture, sampler, skin, plus root glTF.schema. The grammars carry not just the leaf field types but the index relationships between objects, so a generated document is structurally valid by construction.

The generator does not just emit one valid model and randomise leaf values. It deliberately produces cross-field inconsistency. A typical generated document carries 100 nodes, each with three animation channels (scale, rotation, translation) referencing samplers, which reference accessors with independently fuzzed count values, all backed by a small pool of bufferViews with fuzzed stride and byteLength. When two accessors backed by the same bufferView disagree about how many elements live there, you land in the arithmetic mistakes that matter for memory safety.

The Office harness

Each iteration:

1. Generate 100 fuzzed .glb files into the OOXML scaffold's word/media/ folder.
2. Patch word/document.xml and word/_rels/document.xml.rels to reference all 100 models with <am3d:model3d> elements.
3. Re-zip the scaffold into a fresh .docx.
4. Kill any leftover winword.exe, open the new file, and attach WinDbg with a logging command line of the shape .logopen /t <path>; k; r; .logclose; q; q; so every crash drops a timestamped stack and register snapshot next to the input that triggered it.

I ran Word with PageHeap enabled (gflags /p /enable winword.exe). PageHeap turns most heap-adjacent reads and writes into immediate access violations rather than silent corruption. On a closed-source target, that is the difference between a triage-able crash log and an unreproducible hang.

Triage was bucketing by top-frame patterns and minimising by hand on the JSON chunk. Because the GLB header carries lengths, I wrote a small fixer that recomputes both the JSON chunk length and the total file length after edits, so a hand-modified crashing input still loads.

The fuzzer, grammars, JSON template, GLB container, docx-spray harness, and WinDbg automation are mine. The Domato grammar engine they sit on top of is Google Project Zero's, used unmodified.

The simplified crashing object reduced to its smallest reproducible form looks like this:

"scenes": [{"nodes": [0]}],
"nodes":  [{"mesh": 0}],
"meshes": [{"primitives": [
  {"attributes": {"POSITION": 0, "NORMAL": 1}, "mode": 6}
]}],
"accessors": [
  {"name": "offset 0 position", "componentType": 5126,
   "count": 73, "type": "VEC3", "bufferView": 0, "normalized": true},
  {"name": "offset 1 normal",   "componentType": 5126,
   "count": 71, "max": [9999, 9999, 9999], "min": [-9999, -9999, -9999],
   "type": "VEC3", "bufferView": 0}
],
"bufferViews": [
  {"buffer": 0, "byteOffset": 0, "byteLength": 4081,
   "target": 34963, "stride": 6}
],
"buffers": [{"byteLength": 18000}]

Three fields disagree with each other:

• The POSITION accessor declares count: 73 over bufferView 0.
• The NORMAL accessor declares count: 71 over the same bufferView 0.
• The shared bufferView declares stride: 6 and byteLength: 4081.

A VEC3 of componentType 5126 (FLOAT) is normally 12 bytes. A stride of 6 cannot physically fit it. The crash evidence is consistent with the parser deriving its copy length from one of those numbers and its bound from another. When the two numbers disagree, the SSE copy loop runs past r14, reading from (or writing to) memory the buffer was never sized for.

The surviving artifacts show the crash and the memory-corruption behaviour cleanly, but they do not include the patched binary or a binary diff. This page does not name the precise patched function or the precise integer-arithmetic mistake the patch closed; the artifacts do not prove that level of detail.

Microsoft classified CVE-2020-1321 as Remote Code Execution under CWE-119 (improper restriction of operations within the bounds of a memory buffer), CVSS 3.1 base score 7.8 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H), and labelled the issue Exploitation Less Likely on the day of publication. The artifacts preserved here demonstrate, narrowly:

• Reliable crashes in two Microsoft products on attacker-supplied input.
• An out-of-bounds read driven by a length the parser trusts from JSON, visible under PageHeap.
• A separate stack-buffer-overrun fast-fail variant on a different sample, indicating the same underlying bug can corrupt the stack under different attribute paths.

What the artifacts do not demonstrate: a working exploit, an ASLR bypass, or a controlled-write primitive against a real target. This page does not claim those.

A separate variant captured on February 25, 2020 trips c0000409, the security-check / stack-buffer-overrun fast-fail handled by ucrtbase!invoke_watson. It looked like the same family of arithmetic mistake showing up through a different corruption mode: a stack fast-fail rather than the PageHeap OOB-read crash on the canonical sample. Consistent with one underlying bug whose visible failure mode depends on which mesh attribute is currently being populated.

I did not characterise the variant beyond "second corruption mode of the same family." The folder has the WinDbg log; it does not have a per-variant root-cause derivation.

Microsoft classified CVE-2020-1321 as Remote Code Execution. This page does not publish a weaponised chain; it focuses on the fuzzing method, the crash evidence, and the disclosure timeline.

The user-interaction requirement is the standard Office one: a user opens an untrusted document containing the malformed model. Protected View applies in the usual way. Microsoft's Exploitation Less Likely rating reflects the difficulty of turning the primitive into a working exploit on a hardened modern Office build.

1. Grammar over mutation for indexed-graph formats. Most of the Office-format bugs that get found by random byte mutation live near the byte boundaries: header lengths, sentinel values, simple parsers. The interesting bugs in formats like glTF, OOXML 3D embeddings, and PDF live in the cross-references between objects. A grammar that respects the format's structural invariants and deliberately violates the agreements between sibling fields lands deeper. CVE-2020-1321 is a clean instance: the bug needed a real scene with a real mesh and real animations referencing real accessors, and then a precise inconsistency between two fields the parser trusts to agree.
2. Document parsers stay valuable. Every couple of years Microsoft adds a new embedded format to Office: 3D models, SVG icons, equation editors, online-source media. Every new format brings a fresh parser written under shipping pressure. The 3D pipeline shipped in Office at the same time it shipped as a standalone Windows 10 app, which doubled the reachable attack surface for the same bug.
3. Closed-source Windows targets are still tractable. You do not need a sanitiser-instrumented build to find good Office bugs. PageHeap on the target process plus a WinDbg launch line that calls .logopen, dumps the stack and registers, and exits, produces one timestamped log per crash. Pair that with a docx-spray harness that opens 100 fuzzed models per process lifetime, and the throughput is reasonable on a single Windows VM.
4. The workflow mattered more than the individual crash. The most useful thing in this campaign was the loop: generate, package, launch, log, iterate. Most fuzzing posts focus on the crashing input and skip the plumbing. The plumbing is what made the campaign productive. A fuzzer that finds one crash is a story; a fuzzer that finds whichever crashes the parser has, repeatedly, is a tool.

Attribution

The MSRC public advisory credits Menahem Breuer and Ariel Koren of Mimecast Research Labs. The discovery and fuzzing workflow described here - the grammars, the JSON template, the GLB container, the docx-spray harness, the WinDbg automation - were mine, captured from my own working files preserved from that period. Mimecast was the coordinated disclosure channel through which the report reached MSRC, and the public credit is shared between the two named researchers.

What this page does not include

This page is a technical reconstruction, not a release of operational material. It does not publish raw crashing .glb files, the fuzzing corpus DOCX, exact byte-level repro material, private email content, or anything that would function as exploitation guidance. The reasoning is straightforward: the bug is patched, but the value of publishing operational material from a six-year-old campaign is small and the downside is non-zero. The fuzzing method is what matters. The method is what this page publishes.