(none)   anomy-list@mailtools.anomy.net
/ help / lists / applications / search /
  molar.is > lists > anomy-list > 2003-06   / threads / authors / dates / subjects /
 

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

From: Robin Whittle (82018@xyz.molar.is)
Date: Sun 01 Jun 2003 - 17:40:57 GMT

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

    Thanks Bjarni! I did this to line 468:

    > To implement it, search MIMEStream.pm for this line:
    >
    > (\*=|=) # = or *= (RFC2231)
    >
    > and replace it with:
    >
    > \s*(\*=|=)\s* # = or *= (RFC2231)

    This correctly finds the file name in all 16 test cases - thereby dropping the
    .pif file.

    I also tested this:

    Content-Type: application/octet-stream; NaME ==== " unfaithful_Gurls.pif "
    Content-Transfer-Encoding: Base64
    Content-Disposition: attachment; filenamE =" unfaithful_Gurls.pif"

    and it worked fine!

      *** Attached file dropped ***
      An attachment named unfaithful_Gurls.pif was deleted from this
      message because it contained a Windows executable
      or other potentially dangerous file type.

    I guess the problem is how tolerent of malformed MIME headers
    various email clients are, and how to anticipate that and filter
    messages accordingly. If the clients are really messed up and
    happily receive all sorts of rot, then this could be tricky,
    since virus writers will try to exploit such clients and bypass
    the pickier MIME interpretation of programs like Anomy Sanitizer.

    For instance would some clients be so "helpful" as to use the second
    file name in this, whilst the malware filter picks the first?

    I tried a message with both lines like this:

       ="readme.txt PrettyGirls.JPG.exe"

    With the above patch, Anomy Sanitizer reports everything in the quotes
    as the file name and drops it, because it recognises it as an .exe.

    I suppose in a world where people have spaces in filenames, this is
    necessary.

    If I reverse it:

       ="PrettyGirls.JPG.exe readme.txt"

    Anomy Sanitizer does not drop it - it passes it with the lines changed
    to:

      ="PrettyGirls.JPG.exe.readme.txt"

    which would alter any name with a space in it.

    This should not lead to any security trouble, since its the final
    characters after the last full-stop which control how a Windoze
    client "opens" the file.

    Here is a potential problem. If I make both filenames:

      "PrettyGirls.JPG.exe"

    and set bit of the last 'e', then Anomy Sanitizer does not recognise
    it as an .exe file. But maybe some client programs strip off bit 7
    and so would see it as an .exe. Netscape 7 doesn't - but I could
    imagine that some clients might do this. Also, the bit could be
    stripped off in transit, since email is not guaranteed to be sent
    with the 7th bit set.

    If I set bit 7 of just one or the other instance of the filename,
    then Anomy Sanitizer, in both cases, recognises it as an .exe and
    drops it.

    What if the file name was:

        "PrettyGirls.JPG.exe ~"

    Where ~ is some whacky character like a backspace?

    Anomy Santizer does not see it as an .exe. and the backspace is turned
    into underscore.

    But if that '~' is an 0x0A . . . Anomy Sanitizer does not see it as
    an .exe, and so it is passed OK, with malformed headers which perhaps a
    client might recognise as an .exe :

    Content-Type: application/DEFANGED-550

    "
    Content-Transfer-Encoding: Base64
    Content-Disposition: attachment; filename="PrettyGirls.JPG.exe
    "

    This looks wrong. The same thing happens if there is no space and
    so each filename is like this, with the newline straight after the
    ".exe":

    "PrettyGirls.JPG.exe
    "

    Here's another attempt: I make the filename this, with no space
    after the ".exe":

    "PrettyGirls.JPG.exe
     readme.txt"

    Anomy Sanitizer passes it and makes it:

    "PrettyGirls.JPG.exe_ readme.txt"

    This seems fine.

       Cheers

        - Robin


    		•  

    © 2000-2002 Bjarni R. Einarsson       / feedback / legalese / credits /

    Last modified 02-06-2003.
    		bre