Scary-cool: Decompression bombs

Most of us are used to relatively consistent ratios for data compression. The standard ZIP algorithm usually takes ASCII files down by a factor of ten or so, uncompressed binary data by a factor of three, both of those wobbling +/-50%. However, those are averages based on real-world use; if you aim to create a sample dataset purely for a high ratio, you can get 100:1 or better quite easily. Why? Well, if you ever played around with BBSes on a 14.4k modem, you may have seen some quite cool experiments that let you download a megabyte or so in a mere minute, taking advantage of v.32's run-length compression algorithms. (Of course, you were getting a megabyte of meaningless data, most of which was the same byte repeated over and over, but who cares? It was a MEGABYTE! In a MINUTE!)

But what use is there for such tricks now? Decompression bombs, that's what.

Here's an example scenario: A mail arrives at your super-barbed-wire-protected mail gateway. The gzip-compressed attachment - only 7k big - is grabbed by the anti-virus scanner, looking for any suspicious signatures. It starts to decompress it and BANG - the resulting file, over 100 gigabytes, crashes the AV scanner and completely fills the hard drive partition in the process.

Fortunately, a good number of the AV scanners that AERAsec tested aren't too vulnerable, but some require patching. Similarly, sending a gzipped-HTML bomb to a browser will crash a fair few of them. Not so scary, then, but nifty in an admirably-nasty way.