Re: [Declude.Virus] IncrediMail & Blank Folding vulnerability

[Matt]

R. Scott Perry wrote: If there is a reliable and relatively easy way to do so, we'll do it.  The problem, though, is in figuring out what Outlook will and will not accept.  We *know* that will see a virus under certain circumstances, but knowing more than that would require a huge amount of time (we're not the ones that originally discovered any of these vulnerabilities). I think that I've found one of the original posts discussing the Outlook CR vulnerability here: http://cert.uni-stuttgart.de/archive/bugtraq/2002/02/msg00189.html There are clearly some markers in the headers that could be tracked beyond the mere presence of a CR code, i.e. the attachment itself.  Clearly mentioned in this posting are methods using UUEncoding and base64 encoding, and I would think that both could be almost as easily detected.  UUEncoding needs a begin statement followed by a file name at minimum, and possibly also an end statement, base64 attachments buried in message headers, according to this posting, require the presence of a "MIME delimiter" and not just the Content-Type header.  An example is given as follows: From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Date: Tue, 14 Feb 2002 06:06:06 +0100 Subject: Valentine's Present!<CR><CR>begin  virus.exe<CR>M5F%L96YT:6IN(%-E<W-I;[EMAIL PROTECTED]'1P.B\O=W=W+F]P96YO9F9I8V4N;FPO<CR>end I'm not sure what other types of attachments can be handled by Outlook (the only known vulnerable mail client), but I'm sure that they either share one of the same requirements or have another fairly easily trackable patterns. It would seem for this particular vulnerability that the exploit could be fairly easily detected by searching for a required MIME element required for interpreting the attachment.  Once you add a blank line, then the mail client would then be properly interpreting such an attachment, and AV software should be capable of detecting it.  For instance, searching for an occurrence of either a "begin" or a "filename=" after a CR, and before the next proper blank line.  It appears to my far-less learned eyes that many of the vulnerabilities that Declude tracks could be turned into exploit detection through the use of further pattern matching of this type.  The simple presence of a CR character could them be added to BADHEADERS as it is highly associated with spam (if it hasn't already been added). If this can be done, I believe it should be done. Your thoughts??? Matt -- ===================================================== MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ =====================================================