- libarchive
- zip
- debuginfod
- exploitarium
news
libarchive ZIP Declared-Size Boundary Bypass via debuginfod
ZIP64 entry advertises 109 bytes but stock bsdunzip streams 4GiB+109 — debuginfod indexes and serves ELF sections past the metadata boundary.
Summary
A crafted ZIP64 stored entry sets advertised uncompressed size to 109 while the inflated stream is 4,294,967,405 bytes (109 mod 2³²), so archive_entry_size() and stock bsdunzip -t accept a boundary that downstream consumers treat as 109 bytes. debuginfod indexes the embedded ELF build-id and serves .note.gnu.build-id and .poc_marker sections from bytes beyond the advertised limit. This proof-of-concept is one of 30 folders in the Exploitarium collection. OFFSITE.DARK summarizes the upstream README and PoC design; we did not discover or weaponize this flaw.
Key Findings
| Finding | Detail |
|---|---|
| Product / target | Stock libarchive (bsdtar, bsdunzip) + elfutils debuginfod |
| Primitive | Declared size 109 vs actual stream 4GiB+109 with successful decompression |
| Impact | Quota, validation, and indexing logic keyed on entry metadata can miss hidden content served by debuginfod. |
Attack Chain
Sparse ZIP64 (declared 109) → bsdunzip -p streams full size → debuginfod indexes ELF → build-id section fetch past byte 109 → marker section served
Mitigation
Do not trust archive_entry_size() alone for authorization or indexing bounds; validate streamed byte counts; cap debuginfod extraction against declared and observed sizes.