Old as fuck.
Next week on HN, C++ released! :)
Was thinking something simular... First time I discovered this I was a teenager still using dial-up. And apparently the virus-scanner on the school-pc's couldn't handle it :)
Zip Bomb
31–40 of 113 posts
Re: Zip Bomb
#32I 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…
[deleted]
Re: Zip Bomb
#33Re: Zip Bomb
#34I 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…
>> ... eventually filled up the entire disk and bad things happened
I can only imagine what would have happened. Can you share more details about that.
Also, wonder how the mail servers these days are equipped to handle such attachments. Can someone throw light on that? Is it just plain simple to detect these files?
Re: Zip Bomb
#35Earlier quoted context omitted.
Yes they will, there was a post a while back which used this to bomb the browser.
Do you have a link, by any chance?
Unfortunately I do not. This is where that project to store all your browsing history "in the cloud" (preferrably your own "cloud" would have been handy. So you never again miss something and go searching for it again, you know youve seen it -> search in your own history which contains the content right then as it was.
Re: Zip Bomb
#36You 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.
Re: Zip Bomb
#37I 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…
>> ... eventually filled up the entire disk and bad things happened I can only imagine what would have happened. Can you share more details about that. Also, wonder how the mail servers these days are equipped to handle such attachments. Can someone throw light on that? Is it just plain simple to detect these files?
A well-known example of a zip quine:
http://steike.com/code/useless/zip-file-quine/
Compression quines and bombs are a great way to screw up automated systems. Possessing or transmitting them can easily cause a denial of service.
From Wikipedia: A quine is a computer program which takes no input and produces a copy of its own source code as its only output. http://en.wikipedia.org/wiki/Quine_(computing)
Re: Zip Bomb
#38Earlier quoted context omitted.
Yes they will, there was a post a while back which used this to bomb the browser.
Perhaps more concerning is being able to use this to launch a denial of service attack on a server that accepts zipped data. Gzipped requests are unusual with HTTP (no idea how widespread support for it is), but iirc SPDY is compressed by default.
Maybe not at the transport or protocol level, but it wouldn't be too hard to DoS an application server that handles compressed data, such as images.
Make a billion-pixel PNG image that compresses very well, upload several copies simultaneously to a LAMP server running on an average Linode, and watch it run out of memory while trying to create thumbnails with GD.
Re: Zip Bomb
#39Earlier quoted context omitted.
Perhaps more concerning is being able to use this to launch a denial of service attack on a server that accepts zipped data. Gzipped requests are unusual with HTTP (no idea how widespread support for it is), but iirc SPDY is compressed by default.
Maybe not at the transport or protocol level, but it wouldn't be too hard to DoS an application server that handles compressed data, such as images. Make a billion-pixel PNG image that compresses very well, upload several copies simultaneously to a LAMP server running on an average Linode, and watch it run out of memory while trying to create thumbnails with GD.
PHP usually has a pretty reasonable memory limit set, so it would puke on itself pretty quickly.
But I don't think you'd bring the site down.
Re: Zip Bomb
#40You 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.