I'd like to report a not so unimportant problem with anomy. It's not
really a bug in anomy, actually it's just another case of M$
braindeadness ;-)
Lately we've seem some leakage of Worm mails through to our internal
mail system; more specifically, it seems the BugBear worm is
accomplishing this.
Our anomy policy is setup to everything ending in .scr and .pif etc;
scanning is limited to specific type docs (word, etc). That worked fine,
just until recently, as we had reports of some worm mails leaking
through. Strangely, these mails also contained attachements ending in
.scr, which normally should have been blocked.
I've been able to grab hold of one of these messages; it seems the worm
is sending the mail with incorrect mime headers; it does not put quotes
around the filename:
Content-Type: audio/x-midi;
name=Fichiers AUDIO mr. malpoli CD 1.scr
Content-Transfer-Encoding: base64
Content-ID: <T1HIVTvXb5n1k>
This is the corresponding entry in my anomy logs; anomy only 'sees' the
part up to the space.
SanitizeFile (filename="Fichiers", mimetype="audio/x-midi"):
Actually, anomy is following the RFC's, which specific that values are
either a 'token' or a 'quoted string'. 'tokens' cannot contain spaces,
so you're doing the right thing here.
Unfortunately, I've tested with an MS outlook client and it does seem
that it recognizes the incorrect header; this is not the case with mozilla.
My question: is there a way that anomy could be adapted to handle this
case? This does not seem to be a simple case of adapting the regexp ;-)
Tom.
-- Tom Vandepoel Security ArchitectUbizen - Philipsite 5 - 3001 Heverlee - Belgium T: +32 16 28 70 00 F: +32 16 28 71 00
Ubizen - We Secure e-Business - www.ubizen.com