A Vice.com article has brought fresh publicity to an old trick. The so-called “Zip bomb” is a Zip file with a fantastically high compression ratio. Researcher David Fifield created a 46-megabyte file that expands into 45 petabytes. That’s a compression ratio of about a billion. Fifield’s own article provides a lot more technical information.
The article says such files are “so deeply compressed that they’re effectively malware.” That strikes me as a bit of an exaggeration. “Nuisanceware” seems more accurate, if there’s such a word. However, they could be used in a denial of service attack. They could crash a server or browser, and the work removing the expanded files could cause some downtime. A Zip bomb might be a setup for another attack, tying up system resources and distracting administrators.
How a Zip bomb works
The “classic” Zip format has a 4-byte field for the uncompressed file size. That sets the maximum file size to 4 gigabytes (2 gigabytes if it’s interpreted as a signed number). The field could lie about the amount of uncompressed data; whether the file would keep expanding beyond 4 gigabytes depends on the software. The newer Zip64 format allows a file size of 264 bytes, which is infinite for all practical purposes.
Zip files can use a variety of compression algorithms. The most popular one is called “Deflate,” and it has a maximum compression ratio of 1032:1. This is the result of having a maximum run length of 258 bytes. Fifield gets around this with techniques which are very sneaky but follow the Deflate specification.
The bomb contains a very large number of compressed files, and it overlaps files in the Zip container. A Zip file indexes its compressed files in a central directory, which contains an offset to the local file header and compressed data. Nothing stops multiple entries in the central directory from pointing at the same data. But Fifield goes one better, having data serve as both a local file header for one file and file data for another. I still haven’t grokked all the tricks; read his article for yourself.
Protection against (and with) Zip bombs
Some compression/decompression libraries include checking against Zip bombs. They can prevent runaway expansion from filling up a drive, but they may be prone to false positives.
Some people have suggested that a Zip bomb could defend a website. The idea is simply to send one if the user agent appears to be malicious. It might slow down an attacker, but it’s not hard to evade. If the hosting site does legitimate vulnerability scans, it might play havoc with them.
Zip bombs aren’t going to be at the top of anyone’s list of worries, but they’re an interesting curiosity. Without breaking any rules, the simple expansion of a moderate-sized compressed file can fill up the largest disk drive. It’s a reminder that every complex file format can do strange things if you push its rules hard enough.
Like this:
Like Loading...
Related
Mad File Format Science 
Zip bombs: Blown up out of proportion?
A Vice.com article has brought fresh publicity to an old trick. The so-called “Zip bomb” is a Zip file with a fantastically high compression ratio. Researcher David Fifield created a 46-megabyte file that expands into 45 petabytes. That’s a compression ratio of about a billion. Fifield’s own article provides a lot more technical information.
The article says such files are “so deeply compressed that they’re effectively malware.” That strikes me as a bit of an exaggeration. “Nuisanceware” seems more accurate, if there’s such a word. However, they could be used in a denial of service attack. They could crash a server or browser, and the work removing the expanded files could cause some downtime. A Zip bomb might be a setup for another attack, tying up system resources and distracting administrators.
How a Zip bomb works
Zip files can use a variety of compression algorithms. The most popular one is called “Deflate,” and it has a maximum compression ratio of 1032:1. This is the result of having a maximum run length of 258 bytes. Fifield gets around this with techniques which are very sneaky but follow the Deflate specification.
The bomb contains a very large number of compressed files, and it overlaps files in the Zip container. A Zip file indexes its compressed files in a central directory, which contains an offset to the local file header and compressed data. Nothing stops multiple entries in the central directory from pointing at the same data. But Fifield goes one better, having data serve as both a local file header for one file and file data for another. I still haven’t grokked all the tricks; read his article for yourself.
Protection against (and with) Zip bombs
Some compression/decompression libraries include checking against Zip bombs. They can prevent runaway expansion from filling up a drive, but they may be prone to false positives.
Some people have suggested that a Zip bomb could defend a website. The idea is simply to send one if the user agent appears to be malicious. It might slow down an attacker, but it’s not hard to evade. If the hosting site does legitimate vulnerability scans, it might play havoc with them.
Zip bombs aren’t going to be at the top of anyone’s list of worries, but they’re an interesting curiosity. Without breaking any rules, the simple expansion of a moderate-sized compressed file can fill up the largest disk drive. It’s a reminder that every complex file format can do strange things if you push its rules hard enough.
Share this:
Like this:
Related