Live data from Hacker News

Zip Bomb

en.wikipedia.org

61–70 of 113 posts

Re: Zip Bomb

#61

I found a similar file to this (a zip file that contains itself) and e-mailed it to a friend at work. He never received it, but I thought nothing of it (I assumed the email filters just destroyed it). A days later the mail server stops working and the sysadmin turns up at my desk. Turns out the anti-virus scanner had been unzipping and scanning repeatedly. It eventually filled up the entire disk and bad things happen…

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…

Years ago, I was an applications programmer in San Francisco working on a timesharing language called EPS. The mainframes were all in Massachusetts. (Think dial-up terminals, mainframes, and 450 BAUD being considered fast.)

EPS, an interpreted language, was designed to let financial analysts run economic projections. It contained various kinds of arrays.

One day, the systems programmers announced a new feature, first released to the test mainframe: a new structure, called containers IIRC, with the twist being that any cell in a container could itself consist of a container.

You know where this is going:

    For I = 1 to 100
      ContX[1] = ContX
    EndFOR
10 seconds later, EPS on the test mainframe had crashed. Coincidence? Hmmmmmm.

So far, my cover was my inquiring mind. But then I ran the loop again, with the same results.

A minute later, there was Massachusetts on the phone, in the person of my friend Kevin, lead EPS developer: "Hey, the answer is 47. What the hell are you doing?"

Re: Zip Bomb

#62
post #26

Earlier quoted context omitted.

It'd be easier to do something like cat /dev/urandom > big

/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

Re: Zip Bomb

#63
post #12

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.

Wow, the first one crashed my chrome browser. Thanks for sharing

Re: Zip Bomb

#64
The most authoritative-looking reference

http://www.aerasec.de/security/advisories/decompression-bomb...

in this typically thinly referenced Wikipedia article looks to be several years old. What is the current state of the art? Some of the comments already posted as I post this comment talk about the situation "years ago" and at least one comment suggests that this is largely a solved problem, currently. How many wild vulnerabilities like this are there, really?

(I ask questions like this about most "facts" reported in Wikipedia articles, because I am a Wikipedian myself, and I have become painfully aware of how often the "the free encyclopedia that anyone can edit" becomes "the encyclopedia in which every fact is just made up.") From a neutral point of view, is this really much of a problem in day-by-day computer use and online network use?

Re: Zip Bomb

#65

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…

One of many examples of why Windows's arbitrary path length restriction is ridiculous.

Most UNIX systems have a PATH_MAX. It's not just Windows.

Re: Zip Bomb

#66

The most authoritative-looking reference http://www.aerasec.de/security/advisories/decompression-bomb... in this typically thinly referenced Wikipedia article looks to be several years old. What is the current state of the art? Some of the comments already posted as I post this comment talk about the situation "years ago" and at least one comment suggests that this is largely a solved problem, currently. How many wil…

This seems like a ripe opportunity for an enterprising blogger to examine changes that have been made to how we compress things over the past few years and see if any of these changes impacts the potency of the decompression bomb as a kind of, as you said, 'update to the current state of the art'.

Re: Zip Bomb

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

Re: Zip Bomb

#70

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…

One of many examples of why Windows's arbitrary path length restriction is ridiculous.

The write limit should be lower than the read limit.
Post reply on HN