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

A better zip bomb

bamsoftware.com

Post reply on HN
Print view View original

131–138 of 138 posts

Re: A better zip bomb

#131

Post by Theodores »

_urga wrote: post #127
Theodores wrote: post #101

Did anyone notice how neat the HTML was for this article? For once HTML5 elements are in use, sections, asides, figures, correct use of tables - very nice! Only this week did I discover that yahoo and gmail don't let you send zip attachments. I thought this was a bit silly but now I am agreeing with them!

Gmail do let you send zip attachments. It just depends what's in them.

Well it wasn't happy with some source code files I tried to send the other day. None of which were natively executable and all text only. They may have had the 'x' flag set in the permissions. But I was surprised by that, not allowing me to send a bunch of php files.

Re: A better zip bomb

#135

Post by breakingcups »

lloeki wrote: post #80
breakingcups wrote: post #57

Earlier quoted context omitted.

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.

Because anything you give them to fool them (such as fake passports or fake documents to comply with their initial demand), they will turn around and use on innocent victims.

Same goes for files that can crash your computer, they can send that to non-complying victims. Key is to waste as much of their time as possible while giving them as little value as possible.

Re: A better zip bomb

#136

Post by charonn0 »

hinkley wrote: post #129
charonn0 wrote: post #126

Earlier quoted context omitted.

If by "checking" you mean to examine the archive structure to determine whether it's corrupt, and "extracting" you mean "write the archive's contents to disk" then they are fundamentally the same thing. The only difference is that checking sends the content to /dev/null instead of a file. As to why they're writing the contents to disk I can only speculate. Perhaps they're using a library that doesn't expose an "extra…

Have you ever done any work in this area? Because it sounds like you know what you’re talking about, except it’s all nonsense. Zip format can be de/compressed progressively, which is one reason why it’s nice for HTTP transport encoding. The file format is decompressed one record at a time and many or most libraries can give you this as a stream, so it never has to hit disk or be “sent to dev/null”. If you take respon…

Last year I implemented zip reading and zip writing in a hobby project of mine. I'm not an expert, but I know enough to write a working zip reader/writer.

> Zip format can be de/compressed progressively, which is one reason why it’s nice for HTTP transport encoding.

Do you mean HTTP transfer encoding? If so then it's not the zip archive format that's used, but rather the deflate compression algorithm (which zip also uses.)

> The file format is decompressed one record at a time

But not necessarily in the order they appear.

> many or most libraries can give you this as a stream, so it never has to hit disk or be “sent to dev/null”.

My point is that the compressed bytes have to be decompressed and checksummed in both extraction and checking, but after that the bytes may either be written or discarded.

> If you take responsibility for streaming the records to disk (trivial), then you can check the canonical path before writing, and any other filesystem sanity tests you want to do.

That's true but there's nothing wrong with the paths in this case.

Re: A better zip bomb

#137

Post by gynvael »

angel_j wrote: post #117

Can it be packaged as a png?

No. This ZIP bomb workings rely on two important facts:

1. ZIP archive has multiple files.

2. ZIP is an "index+pointers" based format (meaning the Central Directory index of archive files is basically a table of pointers - or rather offsets - telling where to look for data inside the file).

Thanks to these two properties David could create a very clever compressed stream that could be (partially) re-used by multiple files inside the archive.

While one could argue that PNGs do meet the first criteria (multiple compressed separate blocks - vide https://www.w3.org/TR/PNG/#10CompressionOtherUses - do note that multiple IDATs make a single compressed stream, so one has to use these other separate blocks like iTXt, iCCP or zTXt; YMMV for animated PNGs extensions), it certainly doesn't meet the second one - it's a block/chunk format (and by definition blocks are unable to overlap).

One note here is that in case of a faulty block/chunk format parser implementation - one with integer signess/overflow problems related to block size - one might be able to pull an overlapping block trick (see Bug 2 in https://gynvael.coldwind.pl/?id=533 for an example in a different file format).

Re: A better zip bomb

#138

Post by gynvael »

crb002 wrote: post #111

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.

It's an interesting point. For classical ZIPs I actually disagree that it's needed. And then again I do agree for some other potential compression algorithms :)

In case of ZIPs: an implementation can look through the Central Directory index of files and sum up "uncompressed size" fields of all the files, and then check the sum vs the set limits - no prior decompression is needed (this is neither CPU intensive nor requires a lot of memory allocations).

The obvious "gotcha" here is that the "uncompressed size" might be declared low, while the actual data inside the compressed stream might be much higher - this is detectable only when trying to decompress, so it would seem we would fall into your idea (memory allocation / CPU counters). But that actually is not needed, as all good decompression libraries have functions to "decompress at most N bytes" - so the implementation just uses the previously declared "uncompressed size" as the limit, and therefore guarantees that the actual total decompressed size is within the checked (in previous step) total limit.

That said, I do recognize that some decompression algorithms might have possible inputs which get really CPU intensive even for a single byte, though that's not the case for typical "DEFLATE"-using ZIPs (i.e. you probably might structure the decompression stream in a way that does a lot of cache misses, but that's about it).

For non-DEFLATE compression YMMV and your method comes to mind as a decent solution.

Post reply on HN