by Arpit Kumar
04 Jul, 2023
2 minute read
Understanding the Menace of Zip Bombs

Exploring malicious archive file designed to overwhelm and crash the target system by decompressing into an extremely large and resource-intensive volume of data, posing a severe security threat.


Table of Content

This week I was reviewing one of the client requirements where they wanted to send the data in compressed form from our SDK. This would save bandwidth and help reduce network and battery usage on the user device.

So the team implemented a solution where a configuration variable would be passed to the SDK based on client requirement to compress data sent to the backend. This would allow individual clients to decide whether they want to consume the compressed data or not.

Basic architecture has an API gateway to receive the data first and decompress based on the request header. This header is set while data is sent from SDK based on the configuration flag set earlier.

Now coming to unzipping of the data received we checked the performance for peak cpu, memory and network usage while doing our load testing. From my previous experience I was aware of attacks that can be done by scrupulous usage of API.

I will write about the Zip bomb which can make a server slow or crash and cause an outage.

What is a zip bomb ?

Let’s take a case where a server receives a request with a certain payload which is below the max payload size, now when we start unzipping the compressed payload it can easily go over and above the max size.

There are ways where you can zip a lot of files with very low entropy or almost similar content and create a small zip.

An example of this type is 42.zip.

The file contains 16 zipped files, which again contains 16 zipped files, which again contains 16 zipped files, which again contains 16 zipped, which again contains 16 zipped files, which contain 1 file, with the size of 4.3GB.

So, if you extract all files, you will most likely run out of space :-)

16 x 4294967295       = 68.719.476.720 (68GB)

16 x 68719476720      = 1.099.511.627.520 (1TB)

16 x 1099511627520    = 17.592.186.040.320 (17TB)

16 x 17592186040320   = 281.474.976.645.120 (281TB)

16 x 281474976645120  = 4.503.599.626.321.920 (4,5PB)

Nowadays recursive decompression is limited in most of the programs to a level which reduces this risk to a very minimal level.

However, zip bombs can also be employed as a defense mechanism against intruders. In 2017, an Austrian programmer named Christian Haschek proposed the usage of zip bombs as a means to safeguard websites against hackers.

He developed a PHP script that could identify suspicious requests and counter them with a GZip bomb. When the browser or vulnerability scanner responsible for the request attempts to decompress the archive, it either becomes unresponsive or encounters an error, effectively thwarting the intrusion attempt.

Read this blog to for this creative approach - https://www.sitepoint.com/how-to-defend-your-website-with-zip-bombs/

Recent Posts

Understanding Asynchronous I/O in Linux - io_uring
Explore the evolution of I/O multiplexing from `select(2)` to `epoll(7)`, culminating in the advanced io_uring framework
Building a Rate Limiter or RPM based Throttler for your API/worker
Building a simple rate limiter / throttler based on GCRA algorithm and redis script
MicroVMs, Isolates, Wasm, gVisor: A New Era of Virtualization
Exploring the evolution and nuances of serverless architectures, focusing on the emergence of MicroVMs as a solution for isolation, security, and agility. We will discuss the differences between containers and MicroVMs, their use cases in serverless setups, and highlights notable MicroVM implementations by various companies. Focusing on FirecrackerVM, V8 isolates, wasmruntime and gVisor.

Get the "Sum of bytes" newsletter in your inbox
No spam. Just the interesting tech which makes scale possible.