Community hub
0 subscribers8 pages, 0 posts
Recent from talks
All channels
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to Zip bomb.
Nothing was collected or created yet.
Zip bomb
View on Wikipediafrom Wikipedia
In computing, a zip bomb, also known as a decompression bomb or zip of death (ZOD), is a malicious archive file designed to crash or render useless 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]
Details and use
[edit]A zip bomb is usually a small file for ease of transport and to avoid suspicion. However, when the file is unpacked, its contents are more than the system can handle.
A famous example of a 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; 4 GiB − 1 B) file for a total of 4.5 petabytes (4503599626321920 bytes; 4 PiB − 1 MiB) of uncompressed data.[5]
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.[citation needed] 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]
See also
[edit]- Billion laughs attack, a similar attack on XML parsers
- Black fax
- Busy beaver, a program that produces the maximum possible output before terminating
- Email bomb
- Fork bomb
- Logic bomb
- Online algorithm, limit discovered rather than declared
- Time bomb (software)
- ReDoS
- Denial-of-service attack
References
[edit]- ^ 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.
- ^ 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.
- ^ Bieringer, Peter (2004-02-12). "AERAsec - Network Security - Eigene Advisories". Archived from the original on 2016-03-03. Retrieved 2011-02-19.
- ^ 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.
- ^ 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.
Zip bomb
View on Grokipediafrom Grokipedia
A Zip bomb, also known as a decompression bomb or zip of death, is a maliciously constructed archive file—typically in ZIP format—that appears innocuous due to its small size but is engineered to expand exponentially during decompression, overwhelming system resources such as disk space and memory to cause crashes or denial-of-service conditions.[1][2] These files exploit vulnerabilities in compression algorithms by incorporating highly repetitive data or nested structures that lead to massive data inflation, often reaching terabytes or petabytes in uncompressed form from mere kilobytes.[3][4]
Zip bombs function primarily through two mechanisms: recursive designs, where archives contain multiple layers of self-referencing ZIP files that multiply in size with each unpacking level, and non-recursive variants that use overlapping or duplicated content within a single archive to achieve extreme compression ratios.[5][4] For instance, the recursive approach leverages the ZIP format's ability to nest files, causing an exponential explosion—such as a 42 KB file ballooning to 4.5 petabytes across six layers—while non-recursive methods, as detailed in a 2019 technical analysis, overlap file segments to achieve compression ratios up to approximately 100 million-to-one without recursion, making them harder for traditional scanners to detect.[4] A notorious example is 42.zip, an anonymous creation from the early 2000s consisting of 42 kilobytes of compressed data with five to six nested layers, each containing 16 smaller ZIPs that reference identical repetitive text files, resulting in over 4.5 petabytes of output if fully extracted.[5][6]
These attacks are commonly deployed via email attachments disguised as legitimate documents, targeting antivirus software, email servers, or individual systems to disrupt operations, though they lack self-propagation and are not classified as traditional viruses.[3][7] Beyond malice, Zip bombs serve legitimate purposes in software testing, such as evaluating decompression limits in tools like Apache Tika or cloud storage systems.[8] To mitigate risks, modern antivirus solutions employ heuristics to flag suspiciously high compression ratios (e.g., above 1000:1), limit extraction to predefined size thresholds, or analyze file entropy without full unpacking, while users are advised to scan attachments with updated software like Windows Defender and avoid decompressing unknown files on resource-constrained devices.[9][10] Despite advancements, evolving constructions like the 2019 non-recursive bomb highlight ongoing challenges in robust detection.[4]
This approach leverages DEFLATE's efficiency on repetitive data, where each layer's copies compress to a fraction of their expanded size, but decompression multiplies the output geometrically across layers.[21]
A non-recursive alternative, introduced in a 2019 technical analysis, constructs bombs within a single ZIP archive using multiple overlapping files that share compressed data segments from a small "kernel." This technique reuses the kernel across file entries via non-compressed blocks quoting local headers, resulting in quadratic output growth during extraction. It achieves compression ratios exceeding 28 million-to-one (e.g., 10 MB compressed to 281 TB uncompressed) in standard ZIP, with even higher ratios possible using Zip64 extensions for 64-bit sizes, up to around 10^11:1. This method evades recursion-based detection while exploiting DEFLATE limits.[4]
Similar exploitation is possible in other formats using DEFLATE, such as gzip, where LZ77 back-references enable comparable memory ballooning, while bzip2's block-based structure with run-length encoding can be abused for redundancy attacks; however, ZIP's widespread use in archives and its support for multiple files make it the primary vector for such bombs.[22]
Definition and Characteristics
Core Concept
A zip bomb is a maliciously crafted archive file, typically in the ZIP format, that remains compact in its compressed state but expands dramatically upon decompression, potentially overwhelming system resources such as disk space, memory, and CPU cycles.[11][9] This discrepancy arises from the exploitation of compression algorithms' ability to efficiently encode highly redundant data, allowing a small input file to generate an exponentially larger output.[1] The primary purpose of a zip bomb is to execute a denial-of-service (DoS) attack, disrupting the target system or application by forcing it to allocate excessive resources during the unpacking process.[12] By leveraging decompression algorithms' handling of repetitive or recursive structures, these files can cause crashes, slowdowns, or complete system failures without requiring active execution beyond the unpacking attempt.[2] A basic example of a zip bomb involves creating a file filled with repeated null bytes or multiple identical small files, which compress to a minimal size but decompress to terabytes of redundant data, demonstrating significant growth in volume. The concept extends to other archive formats such as RAR or 7z, where similar decompression vulnerabilities can be exploited.[12]Key Properties
A zip bomb exhibits a profound size discrepancy between its compressed and decompressed states, typically appearing as a small file under 1 MB that expands dramatically upon extraction, potentially reaching terabytes or more. For instance, the well-known 42.zip file measures only 42 KB when compressed but can expand to approximately 4.5 petabytes if fully decompressed through its nested structure.[2][4] This extreme ratio, often exceeding 100 million to one in advanced cases, leverages the inherent efficiency of compression algorithms on redundant data.[3] The effectiveness of zip bombs stems from repetition patterns in their construction, employing highly compressible data such as repeated strings of characters or sequences of null bytes (zeros) to achieve compression ratios up to the DEFLATE algorithm's limit of 1032:1 per stream.[4][13] These patterns exploit the algorithm's ability to encode long runs of identical data succinctly, allowing a minimal compressed footprint while generating vast output during decompression. Empty files or uniform binary content further amplify this, as they compress to near-zero size relative to their decompressed volume.[7] Upon extraction, zip bombs induce severe resource consumption, overwhelming system memory, disk space, and CPU cycles, which can trigger out-of-memory errors, complete disk fill-up, or processor exhaustion leading to denial-of-service conditions.[2][7] This behavior manifests as system freezes, crashes, or significant performance degradation, particularly when antivirus scanners or file explorers attempt full decompression without limits.[14] Zip bombs demonstrate platform independence, functioning across major operating systems including Windows, Linux, and macOS, owing to their reliance on ubiquitous standard compression libraries such as zlib, which implement the ZIP format consistently.[14][7] Variants of zip bombs differ in their data composition, with text-based examples utilizing repeated characters to form expansive plain-text outputs, contrasted against binary-based ones that employ null bytes for generating large blocks of empty or zero-filled files.[13][9]Technical Construction
File Format Mechanics
The ZIP file format, originally developed by Phil Katz for PKZIP, organizes archived data through a structured layout that facilitates efficient storage and retrieval. At its core, a ZIP archive begins with a series of local file headers, each preceding the compressed or uncompressed data for an individual file entry. These headers contain metadata such as the filename, compression method, and timestamps. Following the local headers and their associated data blocks, the archive includes a central directory section, which aggregates metadata for all file entries in a single location for quick access during extraction. This directory is terminated by an end of central directory record, which specifies the offset to the central directory's start and the total number of entries, enabling parsers to locate and process the archive's contents without scanning the entire file.[15][16] Compression in ZIP files is specified per entry and primarily employs the DEFLATE algorithm, a lossless method combining LZ77 sliding window matching with Huffman coding to reduce file sizes. DEFLATE is defined in RFC 1951 and allows for two modes relevant to archive construction: "stored" (method code 0, no compression applied to the data) or "deflated" (method code 8, where data is processed through the compression stream). This flexibility enables creators to embed repetitive or highly compressible payloads, such as sequences of identical bytes, which deflate efficiently while declaring large uncompressed sizes. Alternative methods like LZMA or bzip2 are supported in extended ZIP variants, but DEFLATE remains the standard for broad compatibility.[17][15] Each file entry in a ZIP archive includes critical fields in both local and central headers: the uncompressed size (indicating the original data length in bytes), the compressed size (the length of the stored data block), and a CRC-32 checksum (a 32-bit cyclic redundancy check computed over the uncompressed data for integrity verification). These fields, typically 4 bytes each in standard ZIP (with Zip64 extensions for larger values), must align with the actual data to ensure valid archives, though the data descriptor flag (bit 3 in the general purpose flag) allows deferring CRC-32, compressed size, and uncompressed size to a trailing record after the data block. In bomb construction, these elements are set accurately to the payload's properties, allowing small compressed files to declare expansive uncompressed dimensions without immediate detection.[15][16] ZIP files inherently support nesting, where an archive can contain another ZIP file as an entry, treated as opaque binary data under the stored compression method. This recursive capability arises from the format's permission for arbitrary file inclusion, enabling inner archives to reference or embed outer structures, which amplifies decompression depth when extracted iteratively. Such nesting is standard in the format and does not require special flags, though excessive recursion can strain resource limits in unpackers.[15] Common tools for constructing ZIP-based archives, including those exploited for bombs, include open-source utilities like 7-Zip, which implements the full ZIP specification for creating and manipulating entries with specified compression levels. Additionally, programming libraries such as Python's built-inzipfile module provide programmatic control to generate archives by adding files or in-memory data streams, allowing precise control over headers, compression methods, and payload content for testing or development purposes.[18]
Decompression Exploitation
Zip bombs exploit vulnerabilities inherent in the DEFLATE compression algorithm, which combines LZ77 dictionary-based compression with Huffman coding to achieve high compression ratios under normal conditions but enables massive output expansion during decompression. The LZ77 component maintains a sliding window of up to 32 KB of previously decompressed data, allowing back-references that copy sequences from within this window to the output stream; by crafting the compressed data to repeatedly reference and copy nearly the entire window—often overlapping with the current position—the decompressor generates redundant output that grows exponentially, filling memory far beyond the input size.[19] Huffman coding further facilitates this by efficiently encoding these frequent back-references and literal bytes in the compressed stream, permitting a small file to trigger billions of output bytes through minimal input.[20] During runtime, ZIP extractors such as those implemented in libraries like Info-ZIP or PKZIP allocate output buffers primarily on the heap based on the uncompressed sizes declared in the ZIP central directory headers, assuming these sizes are accurate and manageable; however, in bomb constructions, recursive or chained embeddings—where ZIP files contain other ZIP files—bypass size limits if the extractor recursively processes without enforcing global checks, leading to cascading buffer allocations that exhaust available memory or cause out-of-memory errors. Heap usage predominates for large decompressions to avoid stack overflows, but without safeguards, this results in system-wide resource denial through exhaustion, while stack-based temporary buffers for LZ77 window management can contribute to crashes in constrained environments. A common construction technique involves recursive embedding to achieve geometric multiplication of output size, where each layer compresses multiple copies of the previous layer's content. The following pseudocode illustrates a basic recursive ZIP bomb generator in Python, creating nested archives starting from repetitive leaf files:python
import zipfile
import os
def create_bomb_layer(num_copies, depth):
if depth == 0:
# Base case: create innermost ZIP with multiple large repetitive files
leaf_size = 4 * 1024 * 1024 * 1024 # ~4 GB; approximate for 42.zip's 4.3 GB leaves
base_file = 'leaf.txt'
# Write large repetitive file (in practice, use streaming for memory efficiency)
with open(base_file, 'wb') as f:
f.write(b'a' * leaf_size)
# Create innermost ZIP
inner_zip = 'innermost.zip'
with zipfile.ZipFile(inner_zip, 'w') as zf:
for i in range(num_copies):
zf.write(base_file, f'leaf_{i}.txt')
os.remove(base_file)
return inner_zip
# Recurse to create inner layer first
inner = create_bomb_layer(num_copies, depth - 1)
# Create current layer ZIP with copies of inner
current_zip = f'layer_{depth}.zip'
with zipfile.ZipFile(current_zip, 'w') as zf:
for i in range(num_copies):
zf.write(inner, f'inner_{i}.zip')
# Optionally remove inner for chaining
# os.remove(inner)
return current_zip
# Generate 4 nesting levels atop the base (total 5 multiplications): top ~42 KB expands to ~4.5 PB
bomb = create_bomb_layer(16, 4)
import zipfile
import os
def create_bomb_layer(num_copies, depth):
if depth == 0:
# Base case: create innermost ZIP with multiple large repetitive files
leaf_size = 4 * 1024 * 1024 * 1024 # ~4 GB; approximate for 42.zip's 4.3 GB leaves
base_file = 'leaf.txt'
# Write large repetitive file (in practice, use streaming for memory efficiency)
with open(base_file, 'wb') as f:
f.write(b'a' * leaf_size)
# Create innermost ZIP
inner_zip = 'innermost.zip'
with zipfile.ZipFile(inner_zip, 'w') as zf:
for i in range(num_copies):
zf.write(base_file, f'leaf_{i}.txt')
os.remove(base_file)
return inner_zip
# Recurse to create inner layer first
inner = create_bomb_layer(num_copies, depth - 1)
# Create current layer ZIP with copies of inner
current_zip = f'layer_{depth}.zip'
with zipfile.ZipFile(current_zip, 'w') as zf:
for i in range(num_copies):
zf.write(inner, f'inner_{i}.zip')
# Optionally remove inner for chaining
# os.remove(inner)
return current_zip
# Generate 4 nesting levels atop the base (total 5 multiplications): top ~42 KB expands to ~4.5 PB
bomb = create_bomb_layer(16, 4)