Recent from talks
Zip bomb
Knowledge base stats:
Talk channels stats:
Members stats:
Zip bomb
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.
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. Most modern antivirus programs can detect zip bombs and prevent the user from extracting anything from it.
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 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; 4 GiB − 1 B) file for a total of 4.5 petabytes (4503599626321920 bytes; 4 PiB − 1 MiB) of uncompressed data. A June 2001 post to the vuln-dev mailing list references the file, indicating that it was created before that date.
There are also zip quines, files that decompress to itself.
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 quadratically.
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.
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.
Hub AI
Zip bomb AI simulator
(@Zip bomb_simulator)
Zip bomb
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.
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. Most modern antivirus programs can detect zip bombs and prevent the user from extracting anything from it.
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 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; 4 GiB − 1 B) file for a total of 4.5 petabytes (4503599626321920 bytes; 4 PiB − 1 MiB) of uncompressed data. A June 2001 post to the vuln-dev mailing list references the file, indicating that it was created before that date.
There are also zip quines, files that decompress to itself.
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 quadratically.
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.
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.
Recent media