A Zip Bomb is defined as a decompression bomb because it generates an explosion of data that can slow down our computers to the point of freezing them. A very simple technique that uses the compression algorithms of the most famous programs such as Win Zip to create apparently harmless files. The attack falls into the Denial of Service category because it aims to make the system unusable by saturating the available memory resources.
The structure of the file
The famous file 42.zip still circulates on the net, an archive of only 42 KB but capable of unleashing a firepower of about 4 PetaByte. To have a comparison of the PetaByte size just think that our hard disks can have on average some TeraByte. To get a PetaByte you need 1024 Terabytes, so definitely an impressive size!
But let's go back to our 42.zip which is done with a nested structure of archives that goes down for 5 levels. Each level contains 16 archives and each archive is the underlying level made up of another 16 archives. At the fifth level each archive contains a 4GB file and the accounts add up quickly (4.5GB * 16 * 16 * 16 * 16 = 4 718 598GB = 4.5 PT).
When the file is opened, the program will try to open each of the archives contained within and will continue to decompress until it reaches the 4 GB files. It is easy to understand that in this way the capabilities of a computer are saturated in a very short time (both in terms of RAM and possibly from the point of view of the hard disk).
The trick behind a Zip Bomb explosion
But how is it possible to transform over 4 PTs of information into just 42 KB? It is the very nature of the compression algorithms that creates the pitfall from which Zip Bombs spring. In fact, generally these algorithms exploit the repeated parts of the file. Huffman coding, which forms the basis of algorithms such as DEFLATE used by Win Zip or Win Rar, allows you to reduce the size of a file as efficiently as possible . So efficient that in some cases it becomes dangerous!
Typically, repeated information can be grouped by indicating, in the encoding, the symbol (in this case the character) and the number of repetitions of the same. By exaggerating the concept, it is possible to create a huge file that contains only one character repeated many times . Basically the compression algorithm will find the repetition of the same character for n times and encode it as a tuple (character, n), drastically reducing the file size. And here is our Zip Bomb: many text files that contain the same repeated character, nested in various levels!
An ever-present attack
Although many decades have passed since the creation of the first Zip Bomb (it was the early 2000s), it remains an extremely effective attack and is still used today . For example theCVE-2017-16129 vulnerability where the HTTP client is vulnerable to Zip Bomb attacks. In reality, the archive itself does not cause major problems, apart from a heavy use of resources, but it leaves the client vulnerable to other possible attacks.
The same happened not long ago, in 2020, when the vulnerability CVE-2019-9674 was discovered that the Python zipfile.py library up to version 3.7.2 is susceptible to attacks on a Zip Bomb basis. On the NIST website you can see the details of these attacks as well as look for vulnerabilities that have spread in the past.
In conclusion, therefore, there remains the warning to pay extreme attention both when we browse and when we download files of which we do not know the origin. Sometimes even a file sent by a friend could contain this annoying Denial of Service, causing our computer to flounder in search of new resources to open that blessed archive!