A better zip bomb • Hacker News Board

Re: A better zip bomb

#91

Post by wwwhizz » Thu, Jul 04, 2019, 4:53 PM UTC

platz wrote: post #89

d33 wrote: post #82

Surprised nobody commented on this before: > A final plea > It's time to put an end to Facebook. Working there is not ethically neutral: every day that you go into work, you are doing something wrong. If you have a Facebook account, delete it. If you work at Facebook, quit. > And let us not forget that the National Security Agency must be destroyed. Personally I do agree. By the way, I got to meet the author (David F…

Disband the military as well? Open the borders? Decommission the nukes? Break up the banks? Get rid of the filibuster?

No, maybe, sorta, no, definately.

Re: A better zip bomb

#92

Post by ttul » Thu, Jul 04, 2019, 4:54 PM UTC

chrisstanchak wrote: post #87

ttul wrote: 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.

Yea but when you got on a bbs that supported zmodem transfers...

Oh hell yes. Zmodem was the shit. Resumable transfers!

Re: A better zip bomb

#93

Post by speeder » Thu, Jul 04, 2019, 5:08 PM UTC

teddyh wrote: post #70

ttul wrote: 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.

When I was a kid someone gave me a game compressed with ARJ...

Internet didn't existed yet in my country, took me 3 years to figure out how to open that file, and in the meantime I infected my computers multiple times with tons of viruses (seemly packing viruses in unzippers was popular... the one with most viruses was "pkunzip" or something like that)

Re: A better zip bomb

#94

Post by masklinn » Thu, Jul 04, 2019, 5:21 PM UTC

willvarfar wrote: post #43

A 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?

> A lot of modern formats - jar, Apple's pages, etc, come to mind - are just zip files with a different extension.

They use zips as embedded file systems with well-specified structures, I wouldn’t expect them to blindly decompress everything. The format usually defines specific entry points (specially named files) which serve as pointers to the relevant information and link to other files. The bomb part would mostly be ignored filler there.

Re: A better zip bomb

#95

Post by astrobe_ » Thu, Jul 04, 2019, 5:23 PM UTC

gitgud wrote: post #15

r1ch wrote: 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...

Because Autorun so gud. Will people ever learn?

Re: A better zip bomb

#96

Post by SahAssar » Thu, Jul 04, 2019, 5:27 PM UTC

rattray wrote: post #79

_urga wrote: 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.

If it does not "feel ready" I wouldn't want to expose it to random emails or HTTP. There are a lot worse things than zip bombs that can be used to attack and those avenues are basically open to the internet.

Re: A better zip bomb

#97

Post by mulmen » Thu, Jul 04, 2019, 5:31 PM UTC

ddebernardy wrote: post #85

jalk wrote: post #60

Earlier quoted context omitted.

Would it be prejudice to think that the checksum verifying users are not using safari?

Might be, I've no idea. Anecdotally I use Safari - faster, I prefer the UI, and I don't trust Chrome. The only reason I've Chrome around is for the growing number of sites that only work with Chrome. Apps made by Google, in particular, increasingly don't support macOS/Safari. Which I find infuriating, but that's another topic.

Chrome is the new IE.

Re: A better zip bomb

#98

Post by _urga » Thu, Jul 04, 2019, 5:52 PM UTC

willvarfar wrote: post #43

A 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?

DOCX, XLSX are also just ZIP files with the extension renamed.

Re: A better zip bomb

#99

Post by hinkley » Thu, Jul 04, 2019, 6:07 PM UTC

r1ch wrote: 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.

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

Re: A better zip bomb

#100

Post by hinkley » Thu, Jul 04, 2019, 6:13 PM UTC

_urga wrote: 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…

If I recall my PKZip lore, being able to append an updated file to the end of a zip was considered a feature. That leaves a dead copy of the file earlier in the archive, but saves you having to do the floppy shuffle to update one file.

But I don’t recall ever mentioning that fact to someone who already knew it. While you could probably get away with rejecting that file (who still uses that? Some sort of streaming protocol?), it was a feature at one point.