My view on spam and potential denial of service attacks on anti-spam systems

September 19, 2016

In a comment on yesterday's entry on a shift in malware packaging, Jinks asked a very good question:

Since you're working with inspecting zip files, how does your setup handle denial of service attacks against the unzipping part?

Like, let's say I sent you a zipped 30TB sparse file. Or a neverending zip quine.

I've found that many commercial solutions can easily choke on maliciously crafted zip files. Do you have any special provisions in your scripts to prevent these attacks?

The straightforward answer is that we're protected against ZIP quine attacks by having very simple code that only goes one level deep in nested ZIP archives, in large part because Python's zipfile module makes this the relatively natural way to write this code. We're semi-protected against ballooning ZIP archives because we only try to expand .zip files.

But this is a copout. The real answer is that I haven't bothered to write the code to defend against such denial of service attacks, in large part because we don't need it now and I don't expect to ever need it in the future. If I was writing code that would defend a large, prominent organization like Google or Hotmail or something, I would say that I absolutely had to engineer in DOS protection from the start because sooner or later some joker would try sending us one just to see what would happen. But deliberate, focused DOSs against my particular little section of the Internet are unlikely (and if they happen we have plenty of softer targets lying around than the mail system; sometimes such DOSes even happens naturally).

But what about spam, malware, and ransomware, you may ask? Surely they may DOS us this way at some point. My view is that if they do, it will be by accident. If you think about it, spam in general has an extremely good motive to avoid DOS'ing people's email systems. To wit, a DOS'd email system is one that is not letting the spam, malware, or ransomware through (it's not letting anything else through either, but the spammer doesn't care about who else is being affected). If a spammer finds some sort of mail that makes a popular anti-spam system choke, I expect them to carefully avoid it for the same overall reason that they avoid sending things that are easily scored as spam.

In other words, what's valuable to a spammer isn't email that causes a DOS, it's email that bypasses filtering systems somehow. It's possible that such email will DOS our systems, but right now I rate that as relatively unlikely; the stuff that would give my filtering system heartburn are mostly things that would probably lock up an anti-spam system instead of bypass it.

(Maybe I will add an inner-zip length restriction, though. It's probably not hard, and there's good reason to skip trying to check out an inner zip that's too large.)

PS: I suspect that commercial solutions are often not robust against these things for the same reason my code isn't; namely, it's just not something that comes up in the wild. Arguably they should do better, since they're general purpose commercial software.

Written on 19 September 2016.
« A little shift in malware packaging that I got to watch
A surprise with switching to holding keys in ssh-agent »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Sep 19 01:02:45 2016
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.