filename parsing issue

From: Tom Vandepoel (
Date: Mon 14 Oct 2002 - 09:47:36 GMT

  • Next message: Tilman Kastner: "strange string in e-mail causes timeouts"

    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 Vandepoel
    Security Architect

    Ubizen - Philipsite 5 - 3001 Heverlee - Belgium T: +32 16 28 70 00 F: +32 16 28 71 00

    Ubizen - We Secure e-Business -

    hosted by