I performed a full scan on Drive “C” on my computer. After the scan, I had the following results: Five (5) of the files are decompression bomb. I do not understand this term? What should I do to these files? Do they have any damaging effect on the rest of the files or the drive “C” itself?

And yes, it has affected corporate servers in the last few years. I’m not saying that’s anything but a mismanaged server, but sadly people don’t see all the angles all of the time.

Now, this is nowhere near as big a deal as it was when I first wrote the piece (where just about every compression tool tested would fail under some form of decompression tool), but it’s still quite a clever side-channel to use as an annoyance and to say it’s not a problem at all is misleading at best.

If you compress something down very small, good for you. When you try to open it, it doesn’t somehow automagically decompress and make everything explode.

Compression utilities use a memory frame for converting compressed data to decompressed data, and vice-versa. This is directly based on the ‘dictionary sized’ used for compression. It’s much larger for compression than decompression.

If someone sends you a 100GB file, you don’t need 100GB of memory to decompress it. That’s just inane and ’scary’ to suggest. If someone uses a 16MB dictionary size (very common), you only need some 20MB free to successfully decompress.

Depending on compression methods, the maximum dictionary size might be 1MB, or 1GB, but I’ve yet to see anything with a dictionary size of more than 1GB, and never seen anyone use that size. Using presets will typically allow 64MB or less.

The average compression program allows you to easily see the contents, and size (both before and after) by default, before any real decompression is done.

You could theorhetically take up someone’s disk space with such an “attack”, but it’s effortlessly remedied by DELETING the file. This can’t be embedded into anything else, either.

Even comprehensive anti-virus will only scan the first N megabytes of a file by default, or skip things it estimates will take too long. It won’t load the entire file into memory at once then, either.

In such a technical era, it’s ridiculous to come up with this stuff. It was potentially a problem -way- before there was decent software to handle things, but it’d be an extremely unlikely scenario to affect any consumer-level computers built since 1999, let alone corporate ones, or servers.

I don’t think that corporate mail server with 64GB of memory is exactly going to be spending an hour trying to decompress a random ultra-compressed file on its own. Even if it were…that’s not the only process running. It doesn’t somehow “lock up” , which was a problem in the DOS and Windows 3.11 days.

Worst case scenario for a reasonably configured server, that server will churn away…but keeps servicing other requests, marginally slower. It won’t run out of memory. Disk space won’t be exhausted, because users have enforced quotas. Once it expands large enough, it’ll stop expanding, it’ll often delete since the process isn’t complete.

It just isn’t a serious issue, either consumer or corporate, if things are configured in a reasonable way. These days, that’s usually done by default, so to be vulnerable…it would take a great deal of deliberate misconfiguration, and user/sysadmin stupidity. In which case…it’s still not an issue, let alone a serious and crafty attack.