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
I also tested this:
Content-Type: application/octet-stream; NaME ==== " unfaithful_Gurls.pif "
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:
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
If I reverse it:
Anomy Sanitizer does not drop it - it passes it with the lines changed
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:
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
What if the file name was:
Where ~ is some whacky character like a backspace?
Anomy Santizer does not see it as an .exe. and the backspace is turned
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-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
Here's another attempt: I make the filename this, with no space
after the ".exe":
Anomy Sanitizer passes it and makes it:
This seems fine.