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

51–60 of 113 posts

Re: Zip Bomb

#51

Post by exch »

Zenst wrote: post #49

Detection of compression bimbs has improved alot as apposed to over 10 years ago when they realy did cause problems on mail servers. Home AV software detects them, crazily enough my install of GoLang on a windows box has a file that gets flagged as a compression bomb every full system scan. But examples like this happen in many forms, heck windows on some file types/sizes doing thumbnails has done wonderous things li…

> crazily enough my install of GoLang on a windows box has a file that gets flagged as a compression bomb every full system scan.

This may have something to do with Russ Cox's blog post on recursive zip-archives "Zip Files All The Way Down" in Go: http://research.swtch.com/zip

Baseless speculation mode: There is a possibility that the recursive zip file was part of the Go test cases for the gzip package at some point. If it lingers in the mercurial commit history, it may still trigger hits from your AV software.

Re: Zip Bomb

#52

Post by DanBC »

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 used to be able to just password protect the file, and instruct users to enter the password.

Some malware is remarkably unsophisticated and relied on users installing it and giving it permissions to run.

I hope they're not silently rejecting files.

Re: Zip Bomb

#53

Post by DanBC »

ctdonath wrote: post #44

Considering the nature of modern "art" (ex.: "here's a hard drive containing $5M in stolen software!"), and owning a "This T-Shirt is a Munition" (featuring the then-controversial RSA-in-4-lines-PERL code), I'm perversely inclined to find such a "zip bomb" small enough to print the hex or QR code on one business card. The 42kb file is a bit big; any known smaller versions?

(http://www.maximumcompression.com/compression_fun.php)

This has a 115 byte RAR file that expands to 5 Mb. You can probably experiment to get a file just small enough for QR code, with huge output.

(Note that using obscure compressor gives a 24 byte file that expends to 5 Mb.)

Re: Zip Bomb

#54

Post by chrismorgan »

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 won by a considerable margin.)

The school IT manager (who, incidentally, apart from this once I was always on good terms with) was rather annoyed at me the next day, for the nightly backup had fallen over the previous night and he had found the problem. You see, what to me was H:\ was \\galaxy\users$\chrism, which on that server was D:\users\chrism. So that 256-or-so character path became longer than 256 characters on the server and the backup software hadn't been written carefully enough to cope with what was a perfectly valid NTFS path, but not a valid path for the normal Win32 API function calls.

How was I to know it would do that?

Re: Zip Bomb

#55

Post by makmanalp »

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.

Re: Zip Bomb

#57

Post by TazeTSchnitzel »

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…

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

Re: Zip Bomb

#58

Post by krenoten »

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?

"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 than 1 percent, but it was enough. People will do it and even on a locked-down corporate PC, it doesn’t matter. If you can get an HTTP connection back out to the Web, you can then tunnel in over that."

(The Grugq sells high value 0days and is a respected member of the hacking community) http://www.csoonline.com/article/216370/where-is-hacking-now...

Re: Zip Bomb

#60

Post by bct »

thisaccount wrote: post #40
acd wrote: post #36

You can also use the same technique to cause a exhaustion on the number of files/inodes. Ie you format a ext4 partition with crazy number of inodes, then create the zip file containing crazy amount of 0-byte files. Then receiving side has a normal formatted ext3,ext4 partition. Exhaustion on number of inodes. This is not nice so don't do it.

Wonder what would happen if you hid a symlink pointing to root as one of the files. Someone without a doubt would rm-rf.

rm -rf doesn't follow symlinks:

    /tmp $ mkdir -p a/b/c
    /tmp $ mkdir -p a/d/e
    /tmp $ cd a/b/c
    /tmp/a/b/c $ ln -s /tmp/a/d .
    /tmp/a/b/c $ cd ../../
    /tmp/a $ ls */*
    b/c:
    d

    d/e:
    /tmp/a $ rm -rf b
    /tmp/a $ ls
    d
It would be pretty stupid for it to.
Post reply on HN