8 ms·
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 (
by r1ch 7y ago
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.
- gitgud 7y agoWhy would Chrome automatically begin unzipping the file? I'm afraid to even download it now...
- yreg 7y agoSafari 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.
- rimliu 7y agoAnd if someone does not want this there is a checkbox in Preferences under "General": "Open 'safe' files after downloading". Unchecking it will prevent Safari form auto-extracting.
- dddddaviddddd 7y agoHave had this set for many years, I recall some early macOS malware would be present in malformed PDF files that could be downloaded in the background of an infected page & the would open/execute automatically for users who had 'Open safe files' set.
- bestham 7y agoHow can you for instance verify the checksum of the file when it's deleted?
- OrgNet 7y agoWouldn't the decompression fail in that case?
- roelvandijk 7y agoThe 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.
- OrgNet 7y agoIf 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....
- k1t 7y agoThe 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.
- kadoban 7y agoThere 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.
- gchokov 7y agoIt's not always, there's an option to turn this off in the Safari Preferences
- pbhjpbhj 7y agoIf 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?
- qqii 7y agoI accidentally downloaded it without realising this. I'd assume it performs malware scanning. Luckily I was able to end the process from the chrome task manager (shift+escape) without disrupting the rest of the browser.
- masklinn 7y agoOr it could do the same as Safari, open "safe files" by default (which for zip archives means "decompress them").
- zerocool2750 7y agoTIL chrome has a task manager. Thanks for posting the shortcut! +1
- pbhjpbhj 7y ago>Why would Chrome [...] // 'Monitoring'.
- astrobe_ 7y agoBecause Autorun so gud. Will people ever learn?
- yarg 7y agoIf windows defender breaks scanning when it encounters a zip bomb, could that be used to mask malware later in the file?
- deleted 7y ago[deleted]
- astazangasta 7y agoIn such a case could anything actually extract that malware and run it?
- mikepurvis 7y agoSure, as long as that other thing knew not to treat the file as a zip, or had a mechanism to skip over or blank out the first chunk of the file. I wonder how Windows Defender would treat something that looked like a self-extracting archive? Perhaps the archive portion could be this zip bomb affair, but the executable portion had a small change in it to bypass that and do something else nefarious instead, eg hand execution control to a point later in the file.
- yarg 7y agoI 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.
- nolok 7y agoIt probably flags it as unsafe and triggers smart screen. Meaning you have to go out of your way to use the file. As for malware that would be unzipped when using an external zip file; first you would need to trigger the zip bomb on defender but not the external tool, and second defender will still scan the individual files getting unziped by that tool.
- keanebean86 7y agoMaybe do a self extractor that's specially crafted to ignore the zip-bomb part and only extract the malware part? Then the self extractor can execute the malicious code after extracting to memory.
- hinkley 7y agoSee, 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 would be necessary but insufficient for download s from the internet). There were already well known CERT advisories about how relative paths can confuse archive tools, email tools and web servers from Microsoft. Know history or repeat it. I didn’t know “zip bomb” as a phrase but I knew a good bit about compression, so when I needed to fix a problem with zips over 2G I managed to make myself a test fixture that was around 80k without modifying the file format. I think it was just 2.01G of white space.
- deleted 7y ago[deleted]
- deathanatos 7y ago> 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. https://en.wikipedia.org/wiki/Zip_(file_format) https://en.wikipedia.org/wiki/Zip_(file_format)