2

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?)

  • You can use unzip -l archive.zip to list the contents before extracting it, if that helps at all. – Matt Clark Jun 7 '17 at 18:55
1

The ZIP format specifies both compressed and uncompressed file size. Parsing these headers, you should be able to extract the required info.

Give a look here for more information about ZIP headers.

  • Is this failsafe? I have very little concern here over honest mistakes; one would assume that if that header is not tamper-proof, someone attempting to DoS attack with a ZipBomb would be apt to lie about the contents of his package. – K. Alan Bates Jun 7 '17 at 20:22
  • Unfortunately, I don't know if, and how much, ZIP headers are tamper-proof – shodanshok Jun 7 '17 at 20:26
0

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)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.