» Decompression Bombs Part 2

Decompression Bombs Part 2

The piece on decompression bombs was not supposed to be a panic piece, as it seems is implied, rather it was an informative one about a hidden danger in handling compressed files and, in my view, a neat little trick.

To respond to some questions about it: someone asked how you would create the compressed file in the first place since compressing that much data would have to be done in memory, causing you the same problem. Very astute! The answer is that you don’t: the uncompressed data never exists. You need to know enough about your compression algorithm to construct the compressed file directly, writing the output without any real input. This is not that tricky for most formats. The fact of the matter is that you can download decompression bombs quite freely.

In response to a comment by David Russell, and to illustrate some points more clearly, I’m going to discuss some more concrete examples. First of all, David raises the issue that this just means “you restart”. Naively, yes, it does. A restart might not mean much to you, the home user, but it does to quite a few companies. Servers going down means a tangible loss in revenue and respect in the marketplace.

Moreover, denial of service attacks are used to blackmail companies. Mostly these come in the form of botnet attacks, but there’s no reason why a weak company couldn’t be taken down by decompression attacks. Frankly, without adequate defences, a decompression attack is far more effective than malicious pings.

Here are a few scenarios for you:

  1. You are an admin for a company with a reasonable IT infrastructure. Being sensible, your mail server scans all incoming attachments for problems. You’ve also put the servers into a replication configuration so that if one server goes down then your mail queues redirect. Someone sends you a decompression bomb; your mail server goes down pretty quickly because the scan tries to handle it in memory. For every minute the servers are down, you lose X pounds. Depending on how much you’ve thought about this, X can be a large number. Your redundant servers can’t easily help because they’ll start scanning the file and falling over. You have a few solutions: you can switch off scanning (obviously dangerous). Maybe you can switch off replication, though that generally means isolating that queue and dropping the mail on the floor while you figure out what has happened, potentially costing more money.
  2. You are an image storage/processing company who let your users upload images (like, for example, flickr). People upload whatever photos they like and let you display them. Because you want to save a considerable amount of bandwidth, you accept GZip encoded transfer of images. This saves you Y million a year (a conservative estimate for a large site). Someone sends you an image decompression bomb, which expands to some large amount on your servers. Your resources get drained while you either try storing it or sort it out. What can you do? Maybe you take the one time hit in writing it to disk; poor strategy if someone is using this as part of an effective distributed denial of service attack on your site. Maybe you just kill the GZip upload which, as we know, will cost you at least Y million a year; not a good idea if you’re looking to get promoted any time soon.

There are solutions to these scenarios (which I would like to leave as an exercise for my readers, comments anyone?), and I’m sure there are also more tricky scenarios for the really devious (again, I’d love to hear something quite sneaky). The point is that if you accept any content which is compressed, you should be aware of how this could affect you.

My immediate reaction whenever I get back around to thinking about this is: don’t just shell out to gunzip or whatever. Start writing the decompressed file to disk or memory or however you do it, and when you hit your file size limit, stop, in the same way that you don’t accept files over a certain size limit. It requires you to be able to hook into your decompressor, but, well, that should be possible…

Should be, yes, and often is; with the right libraries. However, it does depend on the compression algorithm. In some cases it doesn’t make any sense to send a partial file to disk, because it has to be fully reconstructed, so the tools that would enable this sort of streaming decompression are not readily available: it’s all or nothing.

You are correct in suggesting that this is one of the workable solutions for the later problem (given the right tools): you spool to a temporary file until you hit the size limit or you get a successful completion.

I prefer the age old version of blackmail though the art of kidnapping a CEO’s family.

I’m just old fashioned in that way!

i remember this one time that someone sent me a decompression bomb that crashed my computer when i was halfway through a game of penguin batting (see:http://www.palmtown.com/penguin/) so i found out who it was and then went rounf to his house and smashed his families faces in with a baseball bat and left them for dead and when he came home, his family were all dead in the living room! sweet! then i restarted my computer and broke my high score!

I think that you were more than justified in taking that action, spoonie. Possibly being a little soft on them for not spitting on their broken bodies.

You need to spool to disk or some kind of tempfs. Simply not spooling is your problem, malloc VS write. Now that your spooling you can use quotas.

If you still say, “No I have to use malloc or I can’t use write.” Then you should be using _malloc and put in some sanity checks. If this truly were the problem, then your looking for configurable malloc quotas. Currently your simply looking at an OOM-Killer, not vary nice as you point out.

when i came across compression bombs is when i downloaded demos of games i am possibly going to buy. i guess ALL of them are decopressnion bombs…but a few of the games are STRAIGHT from ubi games..one of the most respected gaming companies.

should i delete them if i dont really use them? and should i ask ubi about this?

I think whatever software is marking these demos as decompression bombs is probably over-reacting, especially if they’re demos from a trusted source; presumably Ubisoft would rather you played their games.

You should delete them if you don’t use them, but I only say that because I would say that regardless of whether they were being marked as decompression bombs or not.

Couldnt you send them the email with the ‘bomb’ at a specific time? Let’s say a bank reconciles their daily transactions each night and you know one of the email addresses associated with that bank. Could you effectively send them the bomb, the mail server decompresses and scans it, and after so many MB’s are decompressed, crashes their server at the very worst time?
Of course their mail server and transaction processing would have to be tied to the same server, but not entirely implausable for a small bank. The bomb is not a huge problem, but can be used as an attack vector for certain situations, like described above, a predetermined time that would cause all sorts of havoc.
Then if their server is down, you may have an avenue in which to insert a virus or malware through email or now inactive virus/spy/IDS scanner.

mike: in theory, yes, you can probably aggravate the situation by picking an awkward time but the situations you describe just wouldn’t happen.

Having a single server for mail and transaction processing? Not even the smallest of banks with a technology footprint would do that.

Also, you can’t “insert a virus… through email” due to the server being down. If the server is down, you can’t send to it. There is no avenue for attack.

So: using known timing attacks to really cause havoc, absolutely. Using decompression bombs for further attack, not so much.

This is a pretty old trick. Years ago when BBS’s would unzip all .zip files that were uploaded (to add advertisements, strip other BBS advertisements, scan, etc.), you could send this sort of "bomb" and crash the BBS. I never thought of using it in modern times, though. Nice article!

I have an old copy of winzip that shows the unzipped file size and the compression percentage. Will these fields be accurate or will they be spoofed by the bomb?

J: you’re right, it’s not a new trick, but still pretty effective, particularly against browsers.

Wilk: Hmm… not sure. I would guess they would be accurate.

when you open an archive with winzip, does it auotmatically load the compressed data into memory? shouldnt you be able to check the compression ratio and compare to the file size?

If I never use winzip will I be safe? Like a dumbass I just opened the file to see what would happen. Nothing. It opened, all is fine. (or is it?)
My antivirus program has me thinking that it’s a virus and my computer will crash the next time I reboot.

Never using a zip program, like Winzip, is an over-reaction (and a pretty untenable position to take). Just be sensible about what you open.

[...] Decompression Bombs Part 2 outlines some real-life examples and answers a few [...]