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

K. Alan Bates
  • 223
  • 2
  • 12

2 Answers2

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.

shodanshok
  • 47,711
  • 7
  • 111
  • 180
  • 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 07 '17 at 20:22
  • Unfortunately, I don't know if, and how much, ZIP headers are tamper-proof – shodanshok Jun 07 '17 at 20:26
1

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)

Olivier Dulac
  • 1,202
  • 7
  • 14
  • I recognized that I never responded to this back when it was pertinent. Fronting my service by quarantining the incoming zip package to an isolated partition was what I ended up doing. I was looking to see if there were any alternative techniques that anyone had come up with that could predict a ZipBomb without having to unpack the contents. I think the answer to that question is "No" – K. Alan Bates Sep 23 '21 at 18:29