Lost in Reception

Six months ago an oversight by McAfee rendered thousands of PCs inoperative. Over the weekend a near-identical oversight by Sourcefire caused an immense number of legitimate email messages to be misclassified as malware.

I commented on the problems that arose when older versions of McAfee’s VirusScan accepted signature updates that required a newer engine version to operate correctly. In addition to pointing out that what happened was not specific to McAfee, I wrote:

Fail safe! Deal with version skew. Bricking a device because its software was out of date is not a reasonable failure mode.

My thinking behind this was that signature matching engines of any sort should (a) know their “version” and (b) have a means for an automatically-delivered signature update to state what engine version it requires. I took for granted that any engine for which these two things were true would, of course, refuse to deploy a signature update which required a newer engine version than was present. This turns out to be an incorrect assumption.

Over the weekend, ClamAV users running an older engine had a problem with this new signature misclassifying legitimate messages as malware:

d41d8cd98f00b204e9800998ecf8427e:0:Exploit.PDF-9669

Setting aside any other considerations for the moment, this is a rather special signature:

$ md5sum </dev/null
d41d8cd98f00b204e9800998ecf8427e  -
$

which suggests that someone at Sourcefire was putting cleverness ahead of simplicity; a rule that a particular element of a PDF file must never be empty should probably be implemented directly in the PDF parser, rather than delegated to a signature match particularly when – as appears to be the case here – the code that can use the signature is rather new.

In any event, ClamAV does have an engine-version specification and checking mechanism, as I had suggested for McAfee’s case half a year ago, but it’s only advisory!

WARNING: Your ClamAV installation is OUTDATED!
WARNING: Local version: 0.92.1 Recommended version: 0.95.3
DON’T PANIC! Read http://www.clamav.net/support/faq
…
WARNING: Your ClamAV installation is OUTDATED!
WARNING: Current functionality level = 26, recommended = 44

I suspect that this is tied up with the view that a little protection is better than none, an engine that knows to simply ignore signatures that it can’t parse and, in the early days anyway, a tradition of making signatures as specific as possible, so the false-positive risk remained negligible. The nett result of otherwise-sensible choices is a serious disruption to the very services that ClamAV is deployed to protect.

So, further to my suggestions of six months ago, add a requirement that engines should never accept signature updates that state a requirement for a newer engine than is present.

The requirement to do something sensible when such a situation is detected (prominently tell the user/admin, etc.) remains an important additional requirement for anyone using a signature-based system.

A final thought: I’m sure it won’t help, but maybe signature and update numbers containing “66″ should be avoided outright; it is perhaps tempting fate, just a little bit :-)