I'm building an ASP.NET application deployed to IIS and I am actively working on following the necessary steps to enable support for Content-Encoding: gzip
There are no current plans for the server I'm working to be deployed to the public web, but I would like to at least investigate options for mitigation of ZipBomb attacks on my server. If my client makes the decision to make their application available to its users through public channels, I would like to already have my ducks in a row.
If I were to be able to figure out how to get GZ POST bodies to come through IIS (active item on SO related to that) what would be my options for detecting the size of the uncompressed content without unpacking the file?
As an illustration- if someone POSTed 42 to my server, decompressing the contents would detonate the bomb. Do any options exist to detect that "this" 42kb represents 4.5PB of data and reject it?
-
How does one programatically detect that zipped content is layered without detonating the bomb and without streaming the content into a fixed size buffer?
(That is to say: is there any utility, service, or methodology that can be applied generally to interrogate the contents of a zip file without actually opening it up?)
Best Answer
Apart from the detection given in other answers, you could mitigate inpacts by forcing unzipping in a specific partition that is not critical to the operation of your server (ie, not the / partition, not the /tmp either, etc).
You could even do this dynamically, for exemple: create (on yet another partition) a 2gb file, format it (mkfs, etc), and mount it on the appropriate mount point (such as: a specific subdir under the user's homedir?) and have the uncompression (including any tmp files) occur in that newly mounted directory. then move the files once u compressed, unmount that partition and "recycle" the 2gb file.
There are multiple ways to mitigate impacts and ensure the zipbomb won't grow too large (it won't be able to go over the partition's size)