Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A better zip bomb (2019)

bamsoftware.com

Post reply on HN
Print view View original

31–40 of 60 posts

Re: A better zip bomb (2019)

#31

Post by EvanAnderson »

arjie wrote: post #14

The fact that ZIP files include the catalog/directory at the end is such nostalgia fever. Back in the day it meant that if you naïvely downloaded the file, a partial download would be totally useless. Fortunately, in the early 2000s, we got HTTP's Range and a bunch of zip-aware downloaders that would fetch the catalog first so that you could preview a zip you were downloading and even extract part of a file! Good tim…

Partial downloads weren't useless, though, as other commenters have said.

The PKZIP tools came with PKZIPFIX.EXE, which would scan the file from the beginning and rebuild a missing central archive. You could extract any files up to the truncated file where your download stopped.

Re: A better zip bomb (2019)

#32

Post by nwallin »

st_goliath wrote: post #26
arjie wrote: post #14

The fact that ZIP files include the catalog/directory at the end is such nostalgia fever. Back in the day it meant that if you naïvely downloaded the file, a partial download would be totally useless. Fortunately, in the early 2000s, we got HTTP's Range and a bunch of zip-aware downloaders that would fetch the catalog first so that you could preview a zip you were downloading and even extract part of a file! Good tim…

> ... a partial download would be totally useless ... no, not totally . The directory at the end of the archive points backwards to local headers, which in turn include all the necessary information, e.g. the compressed size inside the archive, compression method, the filename and even a checksum. If the archive isn't some recursive/polyglot nonsense as in the article, it's essentially just a tightly packed list of c…

At work, our daily build (actually 4x per day) is a handful of zip files totaling some 7GB. The script to get the build would copy the archives over the network, then decompress then into your install directory.

This works great on campus, but when everyone went remote during COVID it wasn't anymore. It went from three minutes to like twenty minutes.

However. Most files change only rarely. I don't need all the files, just the ones which are different. So I wrote a scanner thing which compares the zip file's filesize and checksum to the checksum of the local file. If they're the same, we skip it, otherwise, we decompress out of the zip file. This cut the time to get the daily build from 20 minutes to 4 minutes.

Obviously this isn't resilient to an attacker, crc32 is not secure, but as an internal tool it's awesome.

Re: A better zip bomb (2019)

#33

Post by nwallin »

est wrote: post #22

I wonder if there's any reverse zip-bombs? e.g. A realy big .zip file, takes long time to unzip, but get only few bytes of content. Like bomb the CPU time instead of memory.

Trivially. Zip file headers specify where the data is. All other bytes are ignored.

That's how self extraction archives and installers work and are also valid zip files. The extractor part is just a regular executable that is a zip decompresser that decompresses itself.

This is specific to zip files, not the deflate algorithm.

Re: A better zip bomb (2019)

#34

Post by ks2048 »

nwallin wrote: post #33
est wrote: post #22

I wonder if there's any reverse zip-bombs? e.g. A realy big .zip file, takes long time to unzip, but get only few bytes of content. Like bomb the CPU time instead of memory.

Trivially. Zip file headers specify where the data is. All other bytes are ignored. That's how self extraction archives and installers work and are also valid zip files. The extractor part is just a regular executable that is a zip decompresser that decompresses itself. This is specific to zip files, not the deflate algorithm.

That would be a big zip file, but would not take a long time to unzip.

Re: A better zip bomb (2019)

#35

Post by halapro »

arjie wrote: post #14

The fact that ZIP files include the catalog/directory at the end is such nostalgia fever. Back in the day it meant that if you naïvely downloaded the file, a partial download would be totally useless. Fortunately, in the early 2000s, we got HTTP's Range and a bunch of zip-aware downloaders that would fetch the catalog first so that you could preview a zip you were downloading and even extract part of a file! Good tim…

I hate that the most common video container on the web does this too. Most non-"stream-ready" mp4 files lack even the basic information such as height/width until the file has completed loading.[1]

  [1]: https://forum.videohelp.com/threads/393096-Fixing-Partially-Download-MP4-Files

Re: A better zip bomb (2019)

#36

Post by btilly »

nwallin wrote: post #32
st_goliath wrote: post #26

Earlier quoted context omitted.

> ... a partial download would be totally useless ... no, not totally . The directory at the end of the archive points backwards to local headers, which in turn include all the necessary information, e.g. the compressed size inside the archive, compression method, the filename and even a checksum. If the archive isn't some recursive/polyglot nonsense as in the article, it's essentially just a tightly packed list of c…

At work, our daily build (actually 4x per day) is a handful of zip files totaling some 7GB. The script to get the build would copy the archives over the network, then decompress then into your install directory. This works great on campus, but when everyone went remote during COVID it wasn't anymore. It went from three minutes to like twenty minutes. However. Most files change only rarely. I don't need all the files,…

How would this have compared to using rsync?

Re: A better zip bomb (2019)

#37

Post by colechristensen »

dpifke wrote: post #25
lossyalgo wrote: post #12

Earlier quoted context omitted.

Is it a felony to crash someone's computer?

If it causes more than $5k in damage. Otherwise, it's a misdemeanor. But you probably don't want to be investigated for either.

A deliberate act of revenge against a former employer... wouldn't be given much benefit of the doubt by the courts.

Re: A better zip bomb (2019)

#40

Post by Retr0id »

danudey wrote: post #5

Debian's `unzip` utility, which is based off of Info-ZIP but with a number of patches, errors out on overlapping files, though not before making a 21 MB file named `0` - presumably the only non-overlapping file. unzip zbsm.zip Archive: zbsm.zip inflating: 0 error: invalid zip file with overlapped components (possible zip bomb) This seems to have been done in a patch to address https://nvd.nist.gov/vuln/detail/cve-201…

I think these mitigations are misguided and I've had false-positives at least once. Rather than caring about structural details (overlapping files etc.), decompressors should just limit the overall decompression ratio by default (bytes in vs bytes out). It shouldn't matter how the ratio is achieved.
Post reply on HN