[
https://issues.apache.org/jira/browse/CAMEL-24166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-24166 started by Federico Mariani.
------------------------------------------------
> camel-zipfile / camel-tarfile - maxDecompressedSize is bypassed entirely in
> iterator/splitter mode (decompression-bomb protection defeated)
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-24166
> URL: https://issues.apache.org/jira/browse/CAMEL-24166
> Project: Camel
> Issue Type: Bug
> Components: camel-tarfile, camel-zipfile
> Reporter: Federico Mariani
> Assignee: Federico Mariani
> Priority: Major
> Labels: ai-assisted-review, dataformat
> Fix For: 4.22.0
>
> Attachments: ZipFileMaxDecompressedSizeIteratorIssueTest.java
>
>
> *Severity:* High (security)
> *Affects:* 4.x
> h3. Problem
> {{maxDecompressedSize}} (default 1 GB, documented as throwing {{IOException}}
> when the decompressed size exceeds the cap) is enforced only in the
> single-entry {{unmarshal}} path, where it is passed to {{IOHelper.copy(...,
> maxDecompressedSize)}}. When {{usingIterator=true}}:
> * {{ZipFileDataFormat.unmarshal}} constructs {{ZipIterator}} without passing
> the limit, and {{ZipIterator.getNextElement()}} copies with a plain
> {{IOHelper.copy(zipInputStream, cos)}} (no cap);
> * {{TarFileDataFormat}} / {{TarIterator}} have the same gap.
> The iterator mode is exactly the multi-entry mode used with
> {{.split(bodyAs(Iterator.class)).streaming()}} — the case most exposed to
> hostile uploads — so the protection is absent where it matters most.
> h3. Failure scenario (reproduced)
> {{maxDecompressedSize=10}}, an entry that decompresses to > 10 bytes:
> * {{usingIterator=false}} -> {{IOException}} (correct);
> * {{usingIterator=true}}, iterator fully consumed -> *no exception*, full
> payload decompressed.
> h3. Suggested fix
> Plumb {{maxDecompressedSize}} into {{ZipIterator}} and {{TarIterator}}
> (per-entry minimum; whole-archive if that is the documented intent). Until
> fixed, the docs should note the limit is only honored when
> {{usingIterator=false}}.
> (Note: zip-slip is *not* a default-config vuln — the file producer's
> {{jailStartingDirectory=true}} rejects traversal.)
> h3. Reproducer
> Attached {{ZipFileMaxDecompressedSizeIteratorIssueTest.java}}: control
> ({{usingIterator=false}}) throws as documented (passes); iterator-mode
> assertion expects {{IOException}} and is RED (nothing thrown). The tarfile
> twin shares the pattern.
> ----
> _Reported by Claude Code on behalf of Federico Mariani (Croway). A failing
> JUnit reproducer (confirmed RED on 4.22.0-SNAPSHOT) is attached._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
