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

91–100 of 113 posts

Re: Zip Bomb

#91

Post by gcr »

jefffoster wrote: post #29

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's hilarious -- the viros scanner, which is designed to protect the mail server, was what wound up destroying it in the first place.

Re: Zip Bomb

#92

Post by darkarmani »

lignuist wrote: post #50
omh wrote: post #45

Earlier quoted context omitted.

All of the email virus scanners I've used are aware of this sort of thing, and will have a maximum depth or maximum size for scanning within attachments. I don't think any of them try to "detect" them in any cleverer way.

So I should just place my malicious software deeper than n levels or put it in a huge file? Or are those scanners just rejecting files that are too large or deep?

You can't put it too deep. The scanner should stop attempting to unzip at a certain depth. Presumably, any file that has more than N depth is malicious and should get flagged, but who knows if the person that configured the scanner did id right?

I've worked with a leading commercial scanner that failed to respect the max depth parameter even when set. It would scan for days before we killed it.

Re: Zip Bomb

#93

Post by comex »

krakensden wrote: post #90
duskwuff wrote: post #65

Earlier quoted context omitted.

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

PATH_MAX is defined but meaningless on both Linux and OS X.

Unfortunately, this is not true. The OS X kernel can't deal with paths longer than MAXPATHLEN, which is defined as 1024.

Re: Zip Bomb

#94

Post by derefr »

chrismorgan wrote: post #54
jefffoster wrote: post #29

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…

The NTFS 256-character-path bit me before when I moved a deeply-nested folder from somewhere with a short path (like the root of a disk) to somewhere with a slightly longer one (like my desktop) and then went to delete it. Windows doesn't even complain in this case--it just completely ignores all attempt to delete the folder (even if you, say, put it in the trash and then empty the trash) because it can't complete the process of gathering up the list of paths to delete.

It's very confusing when you're not expecting it--you can dig into the folder and delete all the subdirectories of it that don't have overlong paths just fine, but there'll be one series of empty directories left over that just refuse to go away. Then you flatten them out from their nested configuration, and suddenly the problem goes away.

Re: Zip Bomb

#95

Post by flatline »

gburt wrote: post #84
hoov wrote: post #80

Earlier quoted context omitted.

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

This is also the case on Unix. According to Advanced Programming in the Unix Environment, it is true of many of these so-called limits. The POSIX standard defined many values that were too small for modern-day use, such as _POSIX_PATH_MAX set to 255. The non-posix values are not all defined in limits.h, and must be queried at runtime. Even then, some are indeterminate. But at least you're not relegated to 255 characters;)

Re: Zip Bomb

#96

Post by wolf550e »

DanBC wrote: post #18

Here are some other compression curiosities: ( http://www.maximumcompression.com/compression_fun.php ) It includes a 115 byte rar file that expands to 5 Mb. (That 115 bytes can be squashed down further; one compressor gets it to 39 bytes.); a file that compresses with one software but ends up bigger with another software; etc. some say that file compression is linked to AI - good general purpose compression relies on…

Just read this: http://www.mattmahoney.net/dc/dce.html

Re: Zip Bomb

#97

Post by dsl »

lmkg wrote: post #87
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 starti…

RAR has a built in virtual machine for forwards compatibility with new compression algorithms.

Re: Zip Bomb

#98

Post by halfasleep »

chrismorgan wrote: post #54
jefffoster wrote: post #29

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…

That reminds me of using the undelete utility that came around the Windows 3.1/DOS 6.2 sort of time. All the files it would offer to recover had file names like "testdoc.do?", and if you didn't set the final character it created a file with a wildcard in the name.

Re: Zip Bomb

#99

Post by keeperofdakeys »

makmanalp wrote: post #55
jefffoster wrote: post #29

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…

This is why you set up monitoring. You could notice either a) the long-lasting cpu-eating subprocess or b)just the rapid diminishing of disk space.

When I did a databases class at a University a few years back, we were given a share on a webserver to run php programs on. Naturally they didn't turn off php error logging, and by default php doesn't report errors to the user. One of the students accidentally wrote an infinite-loop, that generated an error on each iteration, filling up the disk. They never did fix the problem, just deleted the log file both times it occurred.

Re: Zip Bomb

#100

Post by philiac »

SoftwareMaven wrote: post #74
krenoten wrote: post #58

Earlier quoted context omitted.

"The Grugq: I’m not joking. You don’t even need to do that. You just send an e-mail which says, you can literally just say, "Run this code." Some of the anti-phishing guys I’ve worked with are just shocked at what happens. I had some friends who worked in corporate security who had to do a cleanup after they got hit with e-mails which said literally, "click on this" and they had 10 or 20 people who did. It was less t…

That was how RSA was breached, which led to the eventual loss of the SecureID master key (and follow-on breeches at DoD suppliers).

What does RSA stand for? I was on their (SecurID) related site, and checked out the "about" page, but the acronym is never defined.
Post reply on HN