anomy-list

1.60 fooled by spaces in MIME headers: W32/Holar.h@MM worm

From: Robin Whittle (81776@xyz.molar.is)
Date: Sun 01 Jun 2003 - 14:02:19 GMT

  • Next message: Bjarni R. Einarsson: "Re: 1.60 fooled by spaces in MIME headers: W32/Holar.h@MM worm"

    Thanks Bjarni for Anomy Sanitizer!

    I am have just installed 1.60, calling it from a Maildrop .mailfilter
    file. The documentation for how I do this will be on my site
    http://www.firstpr.com.au/web-mail/ soon.

    Just as I got it going, along comes some new virus emails to test it! I
    have received two of these W32/Holar.h@MM messages so far. Both seem to
    be from an infected Windows mail server at an ISP in Malta, helpfully
    preceded by a another email a few minutes earlier saying that their
    system detected an outgoing virus addressed to me and that it was
    "quarantined". (I told them off!) So maybe the virus message I got is
    not directly from the virus, but via some scanner which might have
    altered it. The virus is new - 28 May:

      http://vil.mcafee.com/dispVirus.asp?virus_k=100336

    It contains 3 MIME parts. The first is "us-ascii" - just text. The
    second is "application/octet-stream" - a base64 encoded .pif file. The
    third is like this, but is a .doc file. My configuration is to accept
    .txt and .doc, and to drop a .pif. But Anomy Sanitizer does not
    correctly recognise the second attachment as a .pif. It seems to think
    it is "unnamed.bin" - and therefore it accepts it. Its output is:

       Parsing body as DEFAULT.
       CleanUnknown
       SanitizeFile (filename="unnamed.bin",
                     mimetype="application/octet-stream"):

    Whereas it should be:

       Parsing body as DEFAULT.
       CleanUnknown
       SanitizeFile (filename="unfaithful_Gurls.pif",
                     mimetype="application/octet-stream"):

    Here is the first and the start of the second MIME parts:

    ====================

    ----NextMimePart
    Content-Type: text/plain; charset="us-ascii"
    Content-Transfer-Encoding: 7bit

    i've got this surprise from a friend :)
    it really deserves a few minutes of your time.
    Bye

    ----NextMimePart
    Content-Type: application/octet-stream; Name = "unfaithful_Gurls.pif"
    Content-Transfer-Encoding: Base64
    Content-Disposition: attachment; FileName = "unfaithful_Gurls.pif"

    TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    AAAAuAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v

    ===================

    The problem is not the capital letters in "Name" or "FileName". I made
    a test version of the email and sent it to test 1.60's behaviour - and
    the first thing I did was change those to all lower case. The problem
    is in the spaces before and after the two equals signs.

    I named these potential spaces like this:

       Name = "unfaithful_Gurls.pif"
           3 2

           FileName = "unfaithful_Gurls.pif"
                   1 0

    and sent 16 test mails with all the combinations. Here are the results.
     To make it easier to visualise, those combinations for which 1.60 did
    see the ".pif" correctly are shown with a '.' for where the spaces were.
     Those combinations for which 1.60 did not reconise the ".pif" are
    marked 'X'.

    Test Spaces
    file 3 2 1 0

     0 OK
     1 . OK
     2 . OK
     3 . . OK

     4 . OK
     5 X X Bad
     6 X X Bad
     7 X X X Bad

     8 . OK
     9 X X Bad
     A X X Bad
     B X X X Bad

     C . . OK
     D X X X Bad
     E X X X Bad
     F X X X X Bad

    The logic seems to be (3 OR 2) AND (1 OR 0) = filename not recognised.

     - Robin



    hosted by molar.is