Audit PDF decompression resource bounds

[FHoffarth]

Follow-up from #6.

This is not a claim that a vulnerability exists. It is an investigation with a
measurement step before any design step.

Scope

FilePass budgets PNG metadata decompression directly: one DecompressionBudget per file,
16 MiB total, enforced in src/core/png.ts. PDF parsing has no equivalent. pdf.ts and
verify-pdf.ts contain no decompression call of their own — the work happens inside
pdf-lib and pdfjs-dist, outside FilePass's own resource accounting. Whether that is
reachable, bounded by the libraries themselves, or a real gap is unknown.

Known bound today: the 50 MB input ceiling in sniff.ts. That caps the compressed input,
not what it expands to.

Done when

• the PDF decompression paths FilePass actually reaches are mapped — inspection, cleaning,
  the independent pdfjs-dist check, and the raw-byte backstop each count separately;
• existing library and browser limits are identified rather than assumed absent;
• adversarial cases are constructed only for reachable paths;
• the cost is measured before any architecture is proposed;
• the outcome is classified as one of: no issue / bounded risk / real gap;
• if a real gap turns out to be broader than a surgical fix, stop and scope a separate
  design instead of expanding this one.

Explicitly out of scope

• crawler-style fuzzing dumps;
• replacing pdf-lib or pdfjs-dist merely because they are dependencies;
• generalising the PNG budget into a global resource framework before evidence justifies it.

Severity

P2 investigation initially. Re-classify on findings.

🤖 Generated with Claude Code

[FHoffarth]

Phase 1 — measurement complete

Branch audit/pdf-resource-bounds off main@56a9e62. Zero product-code changes; the
sprint ended with an empty diff, which was an allowed and expected outcome.

Where the decompression actually happens

FilePass decompresses nothing itself. readXmp uses PDFRawStream.getContents(), which
returns the raw bytes — the finding correctly reports the compressed size. An early
reading that blamed pdf-lib was wrong: PDFDocument.load on the attack file costs
8 ms / 0 MB. The cost comes from FilePass's own call to independentPdfParse() at the
end of inspectDocument, whose getMetadata() inflates the XMP stream inside pdfjs-dist.

Reachability — checked before measuring

candidate	reachable	measurement
content stream, unreferenced by any decode	no	64 KiB → 3 ms, 0 MB
8 unreferenced flate streams, 16 MiB each	no	129 KiB → 6 ms, 0 MB
catalog /Metadata XMP	yes	below
content stream via the residue path	yes	below
ObjStm / XRef streams	not examined	Phase 2

Path 1 — XMP via getMetadata()

input	payload	ratio	inspectFile	heap	outcome
5 KiB	4 MiB	898:1	165 ms	22 MB	accepted
17 KiB	16 MiB	992:1	566 ms	26 MB	accepted
64 KiB	64 MiB	1019:1	2 025 ms	185 MB	accepted
128 KiB	128 MiB	1024:1	4 158 ms	335 MB	accepted
255 KiB	256 MiB	1026:1	8 632 ms	673 MB	accepted

Linear, no saturation, no refusal. Full pipeline on the 64 KiB file: 4 031 ms,
verdict=verified, downloadable=true — FilePass hands back a clean copy and considers
the file fine.

The source is parsed by pdf.js twice per run: once from pdf.inspect, once from
verifyClean. Read from the code and confirmed by the timing (2 025 × 2 ≈ 4 031). The cost
lands when the file is dropped, before the user asks for anything.

Path 2 — content streams via getTextContent()

Reachable whenever rawMetadataResidue has a candidate: a value promised removed that still
appears in the output. pdf.js then decodes up to 25 pages of content streams, and the
source's content streams are copied into the output unchanged.

input	payload	inspectFile	full pipeline	verdict
17 KiB	16 MiB	15 ms	380 ms	verified
65 KiB	64 MiB	4 ms	1 376 ms	verified

Existing limits

kind of limit	finding
compressed input	50 MB, MAX_BYTES in sniff.ts
decompressed stream	none found in the examined path
object count	none found
image decode	not reachable — nothing is ever rendered

No size guard on flate decoding was found in either library along these paths. That is not a
claim that none exist; the measurements agree with it, being linear to 256 MiB with no
refusal. The limit variable in pdf-lib's FlateStream.js is buffer bookkeeping, not a
ceiling.

Provisional classification: REAL GAP — ARCHITECTURAL

Not surgical, for four reasons:

1. Two separate call sites in two files, with no shared boundary.
2. FilePass cannot bound the decompression, because it does not perform it — unlike PNG,
   there is no reader it holds and no limit it can pass to getMetadata().
3. PDF streams do not declare their decompressed size; /Length is the compressed length,
   so there is no cheap pre-check.
4. The list is demonstrably incomplete — ObjStm and XRef paths are unexamined.

Measurement limits, stated rather than papered over

• Measured in Node. In the browser loadPdfjs installs a worker, so these timings do not
  imply a frozen UI; the memory still lands in the tab. Not verified in a browser yet.
• Stopped at 256 MiB rather than driving to OOM. The ~50 GiB figure implied by the 50 MB
  input cap at ~1024:1 is extrapolation, not measurement.
• Heap deltas between two points only; GC makes individual figures negative. No peak RSS.

Phase 2, agreed scope

A. browser reality check (worker yes/no, main thread responsive yes/no, wall time, tab
survives yes/no — no pseudo-precise worker RSS figures).
B. cancellation and accumulation: does moving on stop the expensive work, or does FilePass
merely stop caring about its result?
C. ObjStm / XRef reachability, via a real type-2 reference.
D. complete the classification.

Implementation remains stopped.

🤖 Generated with Claude Code

[FHoffarth]

Phase 2 — browser reality check, cancellation, ObjStm/XRef

Still zero product-code changes. git diff --stat main is empty.

A. Browser reality check

Production build served by vite preview, real Chromium, the 64 KiB / 64 MiB-payload PDF
built in-page and delivered through the app's own file input.

question	answer
is pdfjs actually in a worker	yes — pdf.worker-C_P5zptD.js, pdf.worker-DTrjDNvb.mjs
main thread blocked	no — zero long tasks across the whole run
inspection, wall clock	1 947 – 3 334 ms
clean + verify, wall clock	7 333 – 11 361 ms
tab	survives
end state	"✓ Ready to share — 1 hidden field removed and verified", download offered
performance.memory	140 MB before / 6 MB after — not informative, discarded

A measurement of mine had to be thrown away. An earlier setInterval stall counter
reported ~1 s stalls and I reported them as main-thread blocking. The browser pane is
document.hidden, where Chrome throttles timers to 1 Hz, so those were artifacts. Redone
with PerformanceObserver('longtask'), and the instrument was validated by recording a
deliberate 500 ms block in the same context — it fires; FilePass's work produces none.

This lowers the severity: the UI does not freeze. The worker does its job.

B. Cancellation and accumulation

The product question — does moving on stop the work, or does FilePass merely stop caring —
has the second answer.

measurement	result
new run finished	+483 ms
abandoned run at that moment	still running
abandoned run finished	+5 077 ms — 4.6 s of work after the user moved on
three attack files at once	3 572 ms vs 1 228 ms alone = 2.91×, fully additive
browser: harmless PDF, idle	744 ms
browser: same file while an abandoned run is active	1 064 ms (1.4×)
AbortController in UI / pdf core	false / false
loadingTask.destroy() used to interrupt	false

runRef in App.tsx filters results; it does not cancel. doc.destroy() in verify-pdf.ts
runs after the await, once the expensive work is already done.

C. ObjStm / XRef reachability

Built with real type-2 xref-stream entries, catalog/pages/page living inside the object
stream. Reachability first: FilePass inspects it, pdf.js opens it (ok=true).

path	input	inflated	time
ObjStm with padding	64 KiB	64 MiB	4 234 ms
XRef stream with padding	64 KiB	64 MiB	451 ms

The ObjStm path costs more than the XMP path (4 234 ms vs 2 025 ms): both parsers have
to inflate it and parse what comes out.

D. Classification: REAL GAP — ARCHITECTURAL, confirmed and widened

Two reachable paths became four:

#	path	triggered by	phase
1	catalog /Metadata XMP	getMetadata()	inspection + verification, 2× on the source
2	content streams	getTextContent()	verification, conditional
3	ObjStm	PDFDocument.load / getDocument	parsing itself
4	XRef stream	PDFDocument.load / getDocument	parsing itself

Paths 3 and 4 decide it. They happen during parsing, before FilePass knows anything about
the file, so there is no point in the pipeline where a budget could be interposed without
either reimplementing PDF parsing or intercepting the bytes before any parser sees them.
That is a design decision, not a call site.

What argues the severity down, and belongs in the design discussion: no UI freeze, no tab
crash, and no fail-open in the sanitisation sense — the file is cleaned and verified
correctly. The cost is CPU and memory on the user's own device, in a local-only tool with no
tenancy boundary. That is a different risk profile from a server-side DoS.

Side finding, moved out of scope

v01-closeout.test.tsx > a reset during processing… failed again during validation on a
completely unmodified tree while the preview server was running, and passed 2/2 once the
server was stopped. That settles the open question from #9: the flake is pre-existing and
load-related, not caused by that PR. Tracked separately as a P2 test-fragility item.

Measurement limits

• Browser pane is document.hidden throughout; rendering behaviour a user would see cannot
  be fully reproduced. longtask measures the underlying main-thread blocking regardless.
• Stopped at 256 MiB rather than driving to OOM; the ~50 GiB implied by the 50 MB cap at
  ~1024:1 is extrapolation.
• Heap deltas between two points only, no peak RSS.

Implementation remains stopped.

🤖 Generated with Claude Code

[FHoffarth]

Closing: investigation complete

Outcome: REAL GAP — ARCHITECTURAL, confirmed.

This issue asked a question rather than asserting a defect, and it has an answer. The chain:

1. hypothesis — PDF parsing may decompress outside FilePass's accounting;
2. Phase 1 measurement — reachability checked before building anything; three of five
   candidates cost nothing, two amplify at ~1024:1;
3. browser counter-check — worker confirmed, main thread not blocked, one of my own
   measurements discarded as a timer artifact;
4. widened — ObjStm and XRef streams are reachable too, and the ObjStm path costs more than
   the one the investigation started from;
5. classification — four paths across two libraries, two of them inside parsing itself, with
   no point where FilePass can interpose a limit without a design decision.

What it is not, equally established: no UI freeze, no tab crash, no incorrect
sanitisation, no fail-open. The file is cleaned and verified correctly; the cost is CPU and
memory on the user's own device.

Zero product-code changes across both phases, which was an allowed and, as it turned out, the
correct outcome. All measurements went to the untracked audit/run/, including the one marked
discarded.

Design work continues in #10 — Design PDF resource containment and cancellation, which
keeps the three questions apart (containment, cancellation/run ownership, concurrency) and
deliberately does not assume an answer.

Separately noted and moved out of this issue: the v01-closeout.test.tsx reset-during-
processing flake is now attributable as pre-existing and load-related — it reproduced on a
completely unmodified tree — so it is no longer entangled with #9.

🤖 Generated with Claude Code