Check inputs to java.util.ZipInputStream
for cases that cause consumption of excessive system resources. 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" whereby a short file is very highly compressed, for instance, ZIPs, GIFs and gzip encoded http contents.
The Zip algorithm is capable of producing very large compression ratios [Mahmoud 2002]. The example below shows a file that was compressed from 148MB to 590KB, a ratio of more than 200 to 1. The file consists of arbitrarily repeated data: alternating lines of 'a' characters and 'b' characters. Even higher compression ratios can be easily obtained using more input data, more targeted input data, and other compression methods.
Any entry in a Zip file whose uncompressed filesize is beyond a certain limit must not be uncompressed. The actual limit is dependent on the capabilities of the platform.
This guideline is a specific example of the more general guideline IDS18-J. Check for inputs that would cause excessive resource consumption.
Noncompliant Code Example
This noncompliant code fails to check the resource consumption of the file that is being unzipped. It permits the operation to run to completion or until local resources are exhausted.
static final int BUFFER = 512; // ... // external data source: filename BufferedOutputStream dest = null; FileInputStream fis = new FileInputStream(filename); ZipInputStream zis = new ZipInputStream(new BufferedInputStream(fis)); ZipEntry entry; while((entry = zis.getNextEntry()) != null) { System.out.println("Extracting: " +entry); int count; byte data[] = new byte[BUFFER]; // write the files to the disk FileOutputStream fos = new FileOutputStream(entry.getName()); dest = new BufferedOutputStream(fos, BUFFER); while ((count = zis.read(data, 0, BUFFER)) != -1) { dest.write(data, 0, count); } dest.flush(); dest.close(); } zis.close();
Compliant Solution
In this compliant solution, the code inside the while loop uses the ZipEntry.getSize()
to find the uncompressed filesize of each entry in a zip archive before extracting the entry. It throws an exception if the entry to be extracted is too large — 100MB in this case.
static final int TOOBIG = 0x6400000; // 100MB // ... // write the files to the disk, but only if file is not insanely big if (entry.getSize() > TOOBIG) { throw new IllegalStateException("File to be unzipped is huge."); } if (entry.getSize() == -1) { throw new IllegalStateException("File to be unzipped might be huge."); } FileOutputStream fos = new FileOutputStream(entry.getName()); dest = new BufferedOutputStream(fos, BUFFER); while ((count = zis.read(data, 0, BUFFER)) != -1) { dest.write(data, 0, count); }
Risk Assessment
Guideline |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
IDS22-J |
low |
probable |
high |
P2 |
L3 |
Bibliography
[SCG 2009] Secure Coding Guidelines for the Java Programming Language, version 3.0
[Mahmoud 2002] Compressing and Decompressing Data Using Java APIs
IDS17-J. Understand how escape characters are interpreted when String literals are compiled 13. Input Validation and Data Sanitization (IDS) 14. Platform Security (SEC)