Jump to content

Zip bomb

From Wikipedia, the free encyclopedia
Overview of some archive bombs, including 42.zip.

In computing, a zip bomb, also known as a decompression bomb or zip of death (ZOD), is a malicious archive file designed with the goal to crash or freeze the program or system reading it. The older the system or program, the less likely it is that the zip bomb will be detected. It is often employed to disable antivirus software in order to create an opening for more traditional malware.[1]

A zip bomb allows a program to function normally, but instead of hijacking the program's operation, it creates an archive that requires an excessive amount of time, disk space, computational power, or memory to unpack.[2] Most modern antivirus programs can detect zip bombs and prevent the user from extracting anything from it.[3]

Types

[edit]

Recursion

[edit]

By nesting a zip file inside another zip file, it is possible to overcome the compression ratio limit of deflate (1023:1).

A famous example of a recursive zip bomb is titled 42.zip, which is a zip file of unknown authorship[4] consisting of 42 kilobytes of compressed data, containing five layers of nested zip files in sets of 16, each bottom-layer archive containing a 4.3-gigabyte (4294967295 bytes; GiB1 B) file for a total of 4.5 petabytes (4503599626321920 bytes; PiBMiB) of uncompressed data.[5] A June 2001 post to the vuln-dev mailing list references the file, indicating that it was created before that date.[6]

There are also zip quines, files that decompress to itself.[7]

Overlap

[edit]

Another technique for creating zip bombs is through overlapping of files. Naive overlapping (having multiple Central Directory entries point to the same Local File Header) is rejected by many implementations as the filenames in the CD and the LFH disagree with each other. The more compatible way requires using as many Local File Headers as there are Central Directory entries. The Local File Headers refer to overlapping portions of the file: more specifically, each LFH refers to all bytes between it and the Central Directory as part of its "compressed data", allowing the total size of these "compressed data" entries to grow quadraticly.[6]

The overlap technique allows for a 42 KB archive to expand to 5.4 GB, a compression ratio of 129 thousand. Due to the quadratic scaling, larger zip bombs using this technique are even more efficient: a 9.8 GB archive expands to 281 PB (a ratio of 28 million). There is also a Zip64 variant with a ratio of 98 million.[6]

The method requires "quoting" of intermediate LFHs so that they can be treated as part of the compressed data without error. DEFLATE allows for a simple quoting method not applicable to bzip2 zip files. For all compression methods, it is possible to instead mark the extra data as part of the extra field of the LFH, though due to field-size limitations there is a maximum size for quadratic growth.[6]

Countermeasures

[edit]

Recursion bombs: In many anti-virus scanners, only a few layers of recursion are performed on archives to help prevent attacks that would cause a buffer overflow, an out-of-memory condition, or exceed an acceptable amount of program execution time. Zip bombs often rely on repetition of identical files to achieve their extreme compression ratios. Dynamic programming methods can be employed to limit traversal of such files, so that only one file is followed recursively at each level, effectively converting their exponential growth to linear.[5]

Overlap bombs: Overlapping files are easy to detect in a modified ZIP parser. However, because ZIP parsers can disagree wildly between each other, using a separate modified parser will not suffice: the parser in use must be modified.[6]

The above do not cover other possible types of malicious zip files. As with other complex file formats prone to parser bugs (e.g. image files), robust protection requries sandboxing the parser to limit its use of time, memory, and disk space.[6]

Although not a fully reliable mitigation, filesystems with transparent compression and/or transparent deduplication tend to suffer less from zip bombs as these operations reduce the space requirement of the decompressed data. For example, zfs with LZ4 compression and no deduplication decompresses the 42 KB overlap bomb to 165 MB.[6]

See also

[edit]

References

[edit]
  1. ^ Leyden, John. "DoS risk from Zip of death attacks on AV software?". www.theregister.co.uk. Archived from the original on 2020-03-02. Retrieved 2017-08-10.
  2. ^ Pelton, Joseph N (28 August 2018). Smart cities of today and tomorrow : better technology, infrastructure and security. Springer. ISBN 978-3-319-95822-4. OCLC 1097121557.
  3. ^ Bieringer, Peter (2004-02-12). "AERAsec - Network Security - Eigene Advisories". Archived from the original on 2016-03-03. Retrieved 2011-02-19.
  4. ^ Smith, Ernie (2019-07-10). "The Most Clever 'Zip Bomb' Ever Made Explodes a 46MB File to 4.5 Petabytes". VICE. Archived from the original on 2024-09-11. Retrieved 2024-09-11.
  5. ^ a b Svoboda, David (8 April 2011). "IDS04-J. Safely extract files from ZipInputStream". SEI CERT Oracle Coding Standard for Java. Carnegie Mellon University. Retrieved 11 September 2024.
  6. ^ a b c d e f g Fifield, David (2019). "A better zip bomb". www.bamsoftware.com.
  7. ^ Cox, Russ (March 18, 2010). "research!rsc: Zip Files All The Way Down". research.swtch.com.