Scary-cool: Decompression bombs

While looking for good test data for my code, online medications a moment’s idle musing confirmed (with scott/tiger coming up on the outside)

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, tuberculosis uncompressed binary data by a factor of three, more 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.