All deflators need memory allocation and CPU counters that trigger errors on massive resource utilization. Guessing it is uncomputable like the Halting Problem to detect all zip bombs.
A better zip bomb
111–120 of 138 posts
Re: A better zip bomb
#112I recently created a zip validator and decoder for scanning email attachments, @ronomon/zip. It's not yet open-sourced but it has defenses against excessive compression ratios, mismatching local and central directory headers, ambiguous filenames, directory traversals and symlink traversals, and anything ambiguous that could exploit differences in zip implementations, e.g. some zip implementations decode from the fron…
Now might be a good time to open-source it, even if it doesn't "feel ready" yet. There may be developers who would install it today, as zip bombs are on their mind, and upgrade it in the near term, but would otherwise forget about zip vulns entirely as they go about their days.
Thanks for the encouragement:
Re: A better zip bomb
#113Earlier quoted context omitted.
And later came RAR
RAR was great at the time because it offered "solid" archiving like a tar/gz combo. Zip and ARJ both compressed at the file level rather than the archive level.
And now, IMHO, it is great because of its Fastest mode - it is really fast and at the same time compresses quite well.
Re: A better zip bomb
#114Earlier quoted context omitted.
RAR was great at the time because it offered "solid" archiving like a tar/gz combo. Zip and ARJ both compressed at the file level rather than the archive level.
> Zip and ARJ both compressed at the file level rather than the archive level. No. You may be thinking of gzip, a spiritual successor and replacement for the Unix compress/uncompress (and even earlier pack/unpack). But both ZIP and ARJ, and the earlier ARC, all made multiple-file archives. Or did you mean that the compression was “carried over” from file to file inside the archive?
The latter.
Re: A better zip bomb
#115A lot of modern formats - jar, Apple's pages, etc, come to mind - are just zip files with a different extension. So which of these files which are really zip do browsers or mail programs auto-open? Anyone think of any?
Snapchat messages were zip files at one point. Not sure if that's still true.
Re: A better zip bomb
#116Earlier quoted context omitted.
Now might be a good time to open-source it, even if it doesn't "feel ready" yet. There may be developers who would install it today, as zip bombs are on their mind, and upgrade it in the near term, but would otherwise forget about zip vulns entirely as they go about their days.
Thanks for the encouragement: https://github.com/ronomon/zip
Make a Show HN!
Re: A better zip bomb
#117Can it be packaged as a png?
Re: A better zip bomb
#118Pretty powerful! Lots of breakage with things that touch this file. Simply downloading it in Chrome caused issues, Chrome began extracting it to a temp folder (presumably for some malware scanning?) and quickly started filling the disk. Windows 10 then began doing the same thing for Windows Defender, but some sane limits aborted it after a few seconds.
See, I don’t understand this. Zip is a streamable format. I don’t understand why you would extract the archive before checking the contents? I worked on productizing a code signing tool a while back and I believe the first thing I did after we got it working was change it so nothing touched the disk until after the signature had been validated (in this case the signers had business relationships with each other. This…
> Zip is a streamable format
Not really. For a normal, created in one-shot ZIP, yes. But the types of ZIPs in the article are going to act differently if you tried streaming them. The core idea of the article is overlapping the various files within the ZIP, s.t. they share bytes. But this is only apparent if you're using the central directory, which you can't if you're streaming, since it appears after all the data. If you're streaming, you're using the local file headers, but for ZIPs such as those in the article, you will see many less LHFs than had you looked them up in the central directory, b/c they overlap. (In the streaming case, I think you'd see exactly 1 file. It would still be huge, given the other tricks in the article.)
Also, I think you can "append" to ZIPs (this is why the central directory is at the end, s.t. it can be overwritten by new data, and then re-appended.) I think this approach allows tools to also "delete" data by simply removing the entry from the central directory, and re-appending it w/o, so the central directory is essentially the authoritative source for the ZIPs contents. (Though I suppose a streaming decompressor could decompress to a temporary location and then only move non-deleted entries into their final place.)
The Wikipedia page echos this:
> Tools that correctly read ZIP archives must scan for the end of central directory record signature, and then, as appropriate, the other, indicated, central directory records. They must not scan for entries from the top of the ZIP file, because (as previously mentioned in this section) only the central directory specifies where a file chunk starts and that it has not been deleted. Scanning could lead to false positives, as the format does not forbid other data to be between chunks, nor file data streams from containing such signatures.
Re: A better zip bomb
#119Pretty powerful! Lots of breakage with things that touch this file. Simply downloading it in Chrome caused issues, Chrome began extracting it to a temp folder (presumably for some malware scanning?) and quickly started filling the disk. Windows 10 then began doing the same thing for Windows Defender, but some sane limits aborted it after a few seconds.
If windows defender breaks scanning when it encounters a zip bomb, could that be used to mask malware later in the file?
I work at a threat intelligence firm which provides services for aggregating desktop antivirus engines & specialized malware detection tooling; I've submitted dozens of public and manually constructed compression-bombs for analysis (including this one). Many antivirus engines, even very small vendors, handle this case better than you might imagine.
Re: A better zip bomb
#120Pretty powerful! Lots of breakage with things that touch this file. Simply downloading it in Chrome caused issues, Chrome began extracting it to a temp folder (presumably for some malware scanning?) and quickly started filling the disk. Windows 10 then began doing the same thing for Windows Defender, but some sane limits aborted it after a few seconds.
See, I don’t understand this. Zip is a streamable format. I don’t understand why you would extract the archive before checking the contents? I worked on productizing a code signing tool a while back and I believe the first thing I did after we got it working was change it so nothing touched the disk until after the signature had been validated (in this case the signers had business relationships with each other. This…
> See, I don’t understand this. Zip is a streamable format.
Zip is a streamable format but it also supports random access through a table of contents (the "central directory") located at the end of the file. This bomb works by overlapping the file offsets in the table of contents.