Validate attacker-controlled xref/ObjStm integers#3
Merged
Conversation
fank
force-pushed
the
claude/validate-xref-bounds
branch
2 times, most recently
from
b22cb63 to
607bb81
Compare
A crafted PDF could panic the parser during Open or object resolution: - xref stream /W with a negative width -> row[a:b] with b < a (slice panic) - ObjStm /First beyond the stream -> content[:first] (slice panic) - ObjStm /N absurdly large -> make([]pair, 0, n) (makeslice panic / OOM) Reject each with an error instead: /W entries must be >= 0, and /First and /N are bounded by the decoded stream length (no ObjStm holds more entries than it has bytes). Tests build minimal xref-stream / ObjStm PDFs (including a valid control) and assert no panic on hostile values.
fank
force-pushed
the
claude/validate-xref-bounds
branch
from
607bb81 to
d8d025f
Compare
Member
|
Very useful! |
Member
|
I hope you don't mind that I've shortened the first line, some user agents cut the first line at 50 something chars. If I should not do this, please tell me |
Collaborator
Author
|
nah its fine |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
A crafted PDF can panic
pdfdisassembleron untrusted input — three attacker-controlled integers reach a slice ormakeunvalidated:/Wwith a negative width → the row decode slicesrow[a:b]withb < a→slice bounds out of range, duringOpen./Firstbeyond the stream length →content[:first]→slice bounds out of range./Nabsurdly large →make([]pair, 0, n)→makeslice: cap out of range/ large allocation.The ObjStm paths fire when the catalog or a name-tree object lives in an object stream (standard in PDF 1.5+). Found while hardening for a downstream consumer that parses untrusted invoice PDFs.
Fix
Validate before use, returning an error instead of panicking:
/Wentries must be>= 0./Firstand/Nare bounded by the decoded stream length — no object stream holds more entries (or a longer header) than it has bytes.Tests
Minimal synthetic xref-stream / ObjStm PDFs:
TestXrefStreamNegativeWidthNoPanic,TestObjStmFirstOutOfRangeNoPanic,TestObjStmHugeNNoPanic— assert no panic on hostile values.TestObjStmCatalogBaseline— a valid ObjStm catalog still resolves (guards against false positives).Hostile values trip Go's slice/
makesize checks (recoverable panics), not real allocations — no large allocations in the test run. Full suite +go vetpass; gofmt-clean.