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

Zip Bomb

en.wikipedia.org

Post reply on HN
Print view View original

81–90 of 113 posts

Re: Zip Bomb

#81

Post by m4rkuskk »

rorrr wrote: post #12
simoncoggins wrote: post #8

I've seen something similar with a PNG file for user supplied profile image [1]. The image was a 10000x10000 all black PNG image which compresses to a pretty small file size. Unless you validate the image dimensions as well as the file size it may cause problems, for instance when GD is used to try to resize it exhausted the memory limit. [1] https://bugs.launchpad.net/mahara/+bug/784978

Out of curiosity I just made two images: 15,000 x 15,000: http://i.imgur.com/WzCyE.png 50,000 x 50,000: http://i.imgur.com/kgmHu.png Both FF and Chrome refuse to open the second one. IE does something weird. Both Opera and Safari figure out the size correctly, but don't display the image.

In case safari crashes and you won't be able to open it, sudo rm -rf ~/Library/Caches/com.apple.Safari did it for me.

Re: Zip Bomb

#82

Post by TazeTSchnitzel »

hoov wrote: post #80
TazeTSchnitzel wrote: post #73

Earlier quoted context omitted.

Perhaps, but Windows's is a bit too low.

While MAX_PATH is 260, most of the Unicode variants of the API functions allow for paths of 32,767 characters [1]. That seems like a decent length. [1] http://msdn.microsoft.com/en-us/library/windows/desktop/aa36...

Oh, that's somewhat reassuring. I'll surely benefit from it in 10 years time. :/

Re: Zip Bomb

#83

Post by Dylan16807 »

fduran wrote: post #62
VMG wrote: post #26

Earlier quoted context omitted.

/dev/zero is probably faster

It is way faster (at least with dd): $ time dd if=/dev/zero of=10MB.dat bs=1M count=10 real 0m0.213s $ time dd if=/dev/urandom of=10MB.dat bs=1M count=10 real 0m8.873s

Or if you want to measure the speed of the source itself:

  $ dd if=/dev/zero of=/dev/null bs=1M count=100
  104857600 bytes (105 MB) copied, 0.0237114 s, 4.4 GB/s

  $ dd if=/dev/urandom of=/dev/null bs=1M count=100
  104857600 bytes (105 MB) copied, 21.501 s, 4.9 MB/s
Also dammit Ubuntu with your Gibis.

Re: Zip Bomb

#84

Post by gburt »

hoov wrote: post #80
TazeTSchnitzel wrote: post #73

Earlier quoted context omitted.

Perhaps, but Windows's is a bit too low.

While MAX_PATH is 260, most of the Unicode variants of the API functions allow for paths of 32,767 characters [1]. That seems like a decent length. [1] http://msdn.microsoft.com/en-us/library/windows/desktop/aa36...

So there's a constant for path length that only applies sometimes...

Re: Zip Bomb

#85

Post by mlvljr »

m4rkuskk wrote: post #81
rorrr wrote: post #12

Earlier quoted context omitted.

Out of curiosity I just made two images: 15,000 x 15,000: http://i.imgur.com/WzCyE.png 50,000 x 50,000: http://i.imgur.com/kgmHu.png Both FF and Chrome refuse to open the second one. IE does something weird. Both Opera and Safari figure out the size correctly, but don't display the image.

In case safari crashes and you won't be able to open it, sudo rm -rf ~/Library/Caches/com.apple.Safari did it for me.

seems not working on windows, a bug?

Re: Zip Bomb

#86

Post by mirkules »

ChuckMcM wrote: post #79
chrismorgan wrote: post #54

Earlier quoted context omitted.

That reminds me of an incident when I was in year 8: seeing how deeply nested I could get directories on Windows. H:\a\a\a\a\..., eventually it stopped working. (I played the game with my friend... he went for creating a new directory at each level, after a little I became sensible and went for copying and pasting, thus multiplying the depth by two each level which of course achieves the goal pretty quickly - so I wo…

Difference between hackers and coders - Rule: "You can have at most 50 sub-directories." coder-action: #define MAX_SUB_DIRECTORY_NUM 50 hacker-action: main(int argc, char *argv[]) { int i; for (i = 0; i Plus experiments. The difference is that the coder is just doing their job so they note the limitation and move on, the hacker is curious and trys to test to see if its a hard limit, a soft limit, a big problem, a lit…

A good developer should be testing for that stuff too. But hackers test these things out of curiosity, developers do it out of attention to detail. A great developer will do both :)

Re: Zip Bomb

#87

Post by lmkg »

jaylevitt wrote: post #69

Comp sci folks: Is predicting whether a compressed file will produce a finite (or, better, reasonably-sized) output roughly equivalent to the halting problem?

It depends on the decompression algorithm. It's possible for that to be the case, but this can only happen if the compressed binary format is essentially a Turing-complete language, for which your decompresser is the interpreter.

I'm not aware of any data formats for which that is the case, but from a theoretical standpoint, eval(s) is a perfectly cromulent decompression algorithm. This fact is essentially the starting point for Kolmogorov complexity.

"Reasonably-sized" is actually an interesting problem in itself. If your decompresser is sufficiently advanced, you could embed a busy-beaver function, which terminates but grows faster than any computable function. I have no idea whether such functions could be expressed with less-than-Turing-complete data formats.

Re: Zip Bomb

#88

Post by tripzilch »

simoncoggins wrote: post #8

I've seen something similar with a PNG file for user supplied profile image [1]. The image was a 10000x10000 all black PNG image which compresses to a pretty small file size. Unless you validate the image dimensions as well as the file size it may cause problems, for instance when GD is used to try to resize it exhausted the memory limit. [1] https://bugs.launchpad.net/mahara/+bug/784978

You can do somewhat better if you host it on a server with gzip compression. Since the PNG has a max dictionary size for the compression, it doesn't optimally compress out all the redundancy. But because the left-over redundancy also forms a repeating pattern (since the black is the same all over the image), gzip shrinks it even further.

I got slightly better results even by doing this with a JPG image, probably because it's based on 8x8 blocks. I used the colour red, but I don't think that matters much.

Correction, looking back to my results, it seems the PNG was smaller after all: png32512.png.gz is 36,077 bytes (a 32000x32000 JPG gzips to about 41k). I forget how I came to the 32512x32512 limit, maybe it was by trial & error, the largest size a browser still opens (probably tested on Firefox and Opera, didn't use Chrome at the time).

I also asked some friends with powerful (lots of memory) computers to try out a webpage that would load this image many times, with unique GET parameters to prevent caching, but apart from loads of harddisk access and maxing the CPU for a bit until they closed the tab, nothing crashy happened (and of course I did inform them what could happen and told them to save any work).

Reliably crashing a browser on a sufficiently high-end (say, gaming) PC, I haven't been able to do it since at least 5 years or so. I might have done better if I'd own a high-end computer myself, of course :) I remember it used to be as easy as making a webpage with 200 full-page DIV layers stacked at 1% opacity :-P

Re: Zip Bomb

#89

Post by tripzilch »

swighton wrote: post #48

I similar attack to mess up XML parsers: http://en.wikipedia.org/wiki/Billion_laughs

Right, you can also do this with SVG images, the group element and something called "xref" (IIRC?) to refer back to other defined groups by their id attribute.
Post reply on HN