Page History

Be careful when extracting entries from java.util.zip.ZipInputStream. Two particular issues to avoid are entry filenames that canonicalize to a path outside of the target directory of the extraction, and entries that cause consumption of excessive system resources. In the former case, an attacker can write arbitrary data from the zip file into any directories accessible to the user. In the latter case, denial of service can occur when resource usage is disproportionately large in comparison to the input data that causes the resource usage. The nature of the zip algorithm permits the existence of zip bombs where a small file, such as ZIPs, GIFs, and gzip-encoded HTTP content consumes excessive resources when uncompressed because of extreme compression.

Wiki MarkupThe zip algorithm is capable of producing very large compression ratios \[ [Mahmoud 2002|AA. References#Mahmoud 02]\]. For example, a file consisting of alternating lines of _a_ characters and _b_ characters can achieve a compression ratio of more than 200 to 1. Even higher compression ratios can be easily obtained using input data that is targeted to the compression algorithm, or using more input data (that is untargeted), or other compression methods.

Any entry targeting a file not within the directory intended by the client program (after filename canonicalization, as per IDS02-J. Canonicalize path names before validating them), must not be extracted or must be extracted to a safe location. Any entry in a zip file whose uncompressed file size is beyond a certain limit must not be uncompressed. The actual limit is dependent on the capabilities of the platform.

...

Bibliography

...

[[Mahmoud 2002AA. References#Mahmoud 02] ]

[Compressing and Decompressing Data Using Java APIs

http://java.sun.com/developer/technicalArticles/Programming/compression/]

]]></ac:plain-text-body></ac:structured-macro>

...

            IDS05-J. Use a subset of ASCII for file and path names