Sometimes the right thing to do about a spate of spam is nothing (probably)

November 29, 2017

We have a program to capture information about what sort of email attachments our users get. As part of its operation it tries to peer inside various types of archive files, because you can find suspicious things there (and, of course, outright bad things, some of them surprising). This program is written in Python, which means that its ability to peer inside types of archive files is limited to what I can find in convenient Python packages. One of the archive formats that it can't look inside right now is .7z files.

Stretching through August, September, and October we received a drizzle of email messages with .7z attachments that our commercial anti-spam system labeled as various sorts of 7z-based malware (a typical identification was CXmail/7ZDl-B). I rather suspect that if our program had the ability to peer into 7z archives it would have found one of the file types that we now block, such as .exe files. While the drizzle was coming in, it was frustrating to sit there with no visibility inside these 7z archives. I was definitely tempted by the idea of using one somewhat complicated option to add 7z support to the program.

I didn't, though. I sat on my hands. And now the drizzle of these 7z-attachment malware emails has gone away (we haven't seen any for weeks now). I'm pretty sure that I made the right decision when I decided on inaction. There are a number of reasons for this, but the narrow tactical one is simply that this format of malware appears to have been temporary (and our commercial anti-spam system was doing okay against it). Waiting it out meant that I spent no time and effort on building an essentially permanent feature to deal with a temporary issue.

(I admit that I was also concerned about security risks in libarchive, since parsing file formats is a risk area.)

It's become my view that however tempting it is to jump to doing something every time I see spam, it's a bad practice in the long run. At a minimum I should make sure that whatever I'm planning to do will have a long useful lifetime, which requires that the spam it's targeting to also have a long lifetime. Adding features in response to temporary spammer and malware behaviors is not a win.

(The other thought is that although some things are technically nifty, maybe there is a better way, such as just rejecting all .7z files. This would need some study to see how prevalent probably legitimate .7z files are, but that's why we're gathering attachment the information in the first place.)

PS: Yes, this malware could come back too; that's why this is only probably the right decision.

Written on 29 November 2017.
« Code stability in my one Django web application
The cost of memory access across a NUMA machine can (probably) matter »

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

Last modified: Wed Nov 29 01:31:29 2017
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.