Live data from Hacker News

A better zip bomb

bamsoftware.com

71–80 of 138 posts

Re: A better zip bomb

#71
post #15
post #2

Pretty 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.

Why would Chrome automatically begin unzipping the file? I'm afraid to even download it now...

>Why would Chrome [...] //

'Monitoring'.

Re: A better zip bomb

#72
post #36

Earlier quoted context omitted.

If windows defender breaks scanning when it encounters a zip bomb, could that be used to mask malware later in the file?

In such a case could anything actually extract that malware and run it?

I don't see why not; just have the payload stored after the bomb - if there are no share dependencies (which there wouldn't be) there's no reason why they shouldn't be independently extractable.

Re: A better zip bomb

#73
post #55

Earlier quoted context omitted.

The idea is to publish the checksum of the archive separately. After downloading the archive you can calculate its checksum and compare with the published checksum. If they differ you known something is up (possibly bad). When a browser helpfully decompresses the archive you can no longer perform this check.

If it fails to decompress because the file is corrupt, the browser would more then likely keep the archive? But if someone replaces the archive with a malicious file that decompress normally, he will also probably change the listed checksum on the download page....

The actual download might be hosted by 3rd party mirrors.

You can compare the checksum to the one on the author's site to ensure the mirror provider didn't alter the file.

Re: A better zip bomb

#74
post #24
post #15

Earlier quoted context omitted.

Why would Chrome automatically begin unzipping the file? I'm afraid to even download it now...

Safari always unzips any downloaded archive, wraps it in a folder and puts it into ~/Downloads. I prefer this functionality as most of the time I do want to unarchive it. I can rearchive it later (or remember to use another browser) when I need to.

If you download a Wordpress plugin, you need to re-up it zipped -- not a major use-case but I could see other similar situations (downloading tarballs). It's an interesting choice.

MS Windows' transparent zip treated as folders works well (it's the same on Kubuntu), one could just do that and pre-cache an uncompressed version; then you get to use the file or open the folder with minimal friction?

Re: A better zip bomb

#76
post #55

Earlier quoted context omitted.

The idea is to publish the checksum of the archive separately. After downloading the archive you can calculate its checksum and compare with the published checksum. If they differ you known something is up (possibly bad). When a browser helpfully decompresses the archive you can no longer perform this check.

If it fails to decompress because the file is corrupt, the browser would more then likely keep the archive? But if someone replaces the archive with a malicious file that decompress normally, he will also probably change the listed checksum on the download page....

There are signature schemes that can fix that issue, and cases where it's useful anyway, like:

Many linux distro isos are available from several different mirrors. Having a secure hash on the original site with the links to mirrors means I don't have to trust the mirror(s).

Another case where the archive hash is useful is when there's some public key crypto involved. I can have a public key from a publisher (gotten either out-of-band or in the past) and the hash can be signed so I can verify it. These schemes would mean that an attacker would at the least need to have compromised a site for an extended period of time (if I have history with the site, the first visit it doesn't do anything extra), or in the case of out-of-band key sharing, multiple communication methods might need to be compromised for an attack to succeed.

But yes, in the common case a hash next to a file link hosted on the same domain really doesn't do anything.

Re: A better zip bomb

#77
post #29
post #24

Earlier quoted context omitted.

Safari always unzips any downloaded archive, wraps it in a folder and puts it into ~/Downloads. I prefer this functionality as most of the time I do want to unarchive it. I can rearchive it later (or remember to use another browser) when I need to.

How can you for instance verify the checksum of the file when it's deleted?

It should be noted, when Safari deletes an extracted archive, it isn’t deleting it; it’s putting the archive in the Trash. You can just turn around and fish it back out. That’s one of the Trash’s roles in macOS: to serve as a place for the OS to put things that you probably don’t want, “but if you do, here’s an opportunity to grab them before they’re gone.” (I’m honestly surprised that every time you Cmd+C, the previous contents of the clipboard don’t end up as a file in the Trash. It’d be perfectly in line with the metaphor they’re going for.)

——

Also, fun bonus fact re: checksumming:

Apple uses the https://en.m.wikipedia.org/wiki/Xar_(archiver) file format for their own software downloads (e.g. App Store downloads; and developer-tools packages from the Apple developer website; and downloading Safari extensions, before those were rolled into the App Store; etc.). Despite Apple being seemingly the sole user of .xar, it’s not an Apple-specific format; rather, it’s developed by OpenDarwin. So you can use it too (for, at least, your macOS-targeted downloads), if you like.

A .xar file contains embedded checksums (both for the archival representations of each file, and for their extracted representations); when Safari auto-unpacks a .xar, the .xar unpacker (Archive Utility?) verifies those checksums as it does so. IIRC, if the verification fails, the extraction stops, what has been extracted so far is deleted, and the user is told the archive is broken and asked whether they want to keep it or move it to the Trash.

A neat thing about .xar extraction, is that it seemingly tags the extracted files with an xattr declaring that they’ve already been checksummed. Apple ships applications like “Install macOS Whatever.app” as a .xar containing an .app bundle containing several mountable .dmg files; normally those .dmg files would do their own checksumming when they mount, but since they came out of a .xar, they know they’ve already been checksummed recently, so they just skip the internal checksumming step. (I think this is one of the main reasons Apple chose to move to .xar; they wanted to be able to make the macOS Installer run faster, by having it not have to do any checksums of its support .dmg files during install.)

So that’s the deeper answer to your question: ultimately, Apple expects people who want archives with checksums, to use .xar or a format like .xar, that does checksumming during extraction.

Re: A better zip bomb

#78
post #70
post #68

I remember being so excited when the zip format came out. Prior to zip, we suffered with the arc format. At 2400 baud, the difference in compression was very very significant.

I always preferred ARJ; I remember it having both better compression and more useful options than ZIP.

And later came RAR

Re: A better zip bomb

#79
post #67

I 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.

Re: A better zip bomb

#80

i have a Nigerian prince in my inbox why might be in for a treat....

In my time as a scambaiter, one of the most important lessons taught to everyone was: "Don't weaponize them"

Honest question: why? Seems like there is a nice story behind this claim.
Post reply on HN