There are common methods allowing to bypass almost any content filtering software (antiviral products, CVP firewalls, mail attachment filters, etc). I believe multiple products are vulnerable. Contents: I. Bypassing attachment detection or invalid detection of attachment type. 1. Encoded filename or boundary in Content-Type/Content-Disposition 2. Multiple filename or boundary fields in Content-Type / Content-Disposition 3. Exploitation of poisoned NULL byte 4. Exploitation of unsafe fgets() problem 5. MIME part inside MIME part 6. UUENCODE problems 7. Additional space symbol 8. CR without LF 9. Prohibited characters in the filename 10.Skipped file name 11.Endless UUEncoded messages 12.Different filenames for Content-Type and Content-Disposition 13.Case sensitivity of Content-Type and Content-Disposition 14.Additional dot in filename 15.RFC 2231 encoding for filenames 16.Missed MIME-Version header 17.Incomlete encoding 18.Empty boundary 19.Corrupted MIME 20.MIME nesting II. Bypassing detection of potentially dangerous content 1. Inability to check Unicode (UCT-2, UTF-16) content 2. Inability to check UTF-7 content 3. Inability to check file marked as UTF-7 Content 4. Inability to check content with short Content-Length 5. Inability to check message/partial MIME type 6. Inability to check chunked HTTP encoding 7. Inability to check gzip'ed HTTP encoding 8. Inability to check binary encoding 9. Bypassing filters with special characters 10.Exploitation of stream buffering 11.Exploitation of resumed connection 12.Content encryption 13.Different content type detection technique 14.META tag in document body 15.Scripting via stylesheets 16.8-bit to 7-bit ASCII conversion 17.Inability to parse Halfwidth/Fullwidth Unicode characters 18.Overlong UTF sequences 19.Exploiting Content-Type autodetection III. What should be done? 1. What client software vendor should do. 2. What server software vendors should do. 3. What system administrators should do. 4. What content filter developers should do. IV. What was actually done: See: made by 3APA3A and offtopic in October, 2004 made by Simon Howard in November, 2007. I. Bypassing attachment detection or invalid detection of attachment type. Imagine administrator who set his server to strip mail attachments with dangerous extensions: .exe, .com, .bat, .cmd, .pif, .scr etc. No he sure, that his user can't get executable file via e-mail. He's wrong. Because server and client software may use different ways to find attachments and to discover the type of attachments. Also, some servers have vulnerabilities preventing them from discovering attachments. There are few exploitation scenarios: 1. Encoded filename in Content-Type/Content-Disposition Mail software finds that MIME part is actually attachment by the 'name' attribute in Content-Type of 'filename' in Content-Disposition. If neither name nor filename attribute present most software will faild to find attachment. name and filename may contain encoded-words. Usually Content-Type looks like Content-Type: application/binary; name="eicar.com" or Content-Type: application/binary; name="=?us-ascii?Q?eicar=2Ecom?=" But there are different sub-variants server software may fail to check: Content-Type: text/plain; name==?us-ascii?Q?eicar.com?= or name=eicar.com name=""eicar.com name=."eicar.com" name=eicar .com name="eicar.com name==?us-ascii?Q?eicar.com?= name==?us-ascii?Q?eicar?=.com name==?us-ascii?Q?eicar?= =?us-ascii?Q?.com?= name="eicar.=?us-ascii?Q?com?=" name="eicar.=?us-ascii?Q?com?= name=eicar.=?us-ascii?Q?com?= name=eicar.=?us-ascii?Q?co?=m in case of names like this many programs fail to detect .com extension or to find attachment at all (please note: base64 may be used instead of quoted-printable). Another example is name="=?us-ascii?B?eica.com in this case encoded word is incomplete and it's not clear if it should or shouldn't be decoded from base64. It will depend on client program implementation. Good content filtering software should try both cases. Some programs also rely on boundary to detect attachments. If Content-Type contains something like boundary==?koi8-r?Q?aaa?= they may try to use boundary "aaa" while most clients will use exactly "=?koi8-r?Q?aaa?=". Another case is then software tries to decode enocded word, for example multiple programs miss attachment if it's marked as Content-Type: text/plain;=?koi8-r?B?;name="eicar.exe";?= 2. Multiple filenames/boundaries. Another one point is how software behaves if there multiple name or boundary attributes. Example: Content-Type: text/plain; name="safe.txt"; name="eicar.com" Most client programs will use last name or boundary, but good content filtering software should block that kind of messages or check all possible situations. 3. Exploitation of "poisoned null byte". I belive there is not need to explain that ASCII 0 byte may be string terminator. NULL byte may present in data as is or may be encoded using base 64 or quoted printable. There is a lot of situation where server and client software may react to null byte in different way. At least Outlook Express treats NULL as CRLF. 3.1 Filename and boundary. There is no need to explain that both name="file.txt\0.exe" and name="file.exe\0.txt" may be dangerous and boundary="aaa\0bbb" may be treated as is or as "aaa". 3.2 MIME header and MIME body Imagine there is a MIME part with Content-type: text/plain; name=eicar.com \0Any: text EICAR-SIGNATURE Client software may think that EICAR-SIGNATURE is beginning of file data, while content filtering software will think it's a part of header. Or vice versa. The only good solution is do not allow NULL byte in headers. 4. Exploitation of unsafe fgets() problem I've used "unsafe fgets()" term some time ago regarding to mailbox parsing problem in few application. This is input validation bug in programs processing string input then long string are processed incorrectly in specific situation. It has nothing common with overflowing some buffer. Let's review small example. Imagine next code looks for empty string of only '\n' to find the end of MIME headers: while ( fgets(buffer, BUFFERSIZE, input) ) { ... if (*buffer == '\n') header = 0; ... } There is a bug in this code. Imagine the string of exactly BUFFERSIZE bytes long (last byte is '\n'). First fgets() call will return BUFFERSIZE-1 characters. Second call will return the string of only '\n' character. It will be incorrectly believed to be empty string. A lot of client and server software has this kind of bugs. It makes it possible to fool this software to detect headers there they shouldn't for exampe: Header:(number of spaces)Content-Type: text/plain; name="eicar.exe" or like in case of 3.2 to treat some header fields as a part of the body. 5. MIME part inside MIME part This bug is very common for software which strips attached files. Example: --aaa Content-Type=text/plain; --bbb Content-Type=application/exe; name="eicar.com" EICAR SIGNATURE --bbb-- name="eicar.com" EICAR SIGNATURE --aaa then bbb part will be removed aaa part will contain eicar.com 6. UUENCODE problems UUENCODE is older format for file attachments that doesn't require MIME part. In classic case uuencoded file begins with begin XXX filename.ext (XXX - file permissions in octal encoding). The problem is if filename contains spaces, for example begin 666 eicar .com is valid filename but multiple attachment filter fail to check everything after space. 7. Additional space symbol Additional space symbol at the end of filename or boundary may be treated in different ways by client and mail filtering software. For example: boundary=aaa\r\r\n may be treated by client software as either "aaa" or "aaa\r" and both cases should be checked. same thing is with filename in MIME or UUENCODE. 8. CR without LF At least Outlook Express treats without as end of line. It makes it possible to create Content-Type headers and body invisible for content filtering software (was reported by Valentijn Sessink) BTW: older versions of The Bat! crash on without , see 9. Prohibited characters in the filename As it was pointed by Aidan O'Kelly filename may contain some character MUA will strip, for example eviltrojan."e"x"e will be treated by Outlook Express as eviltrojan.exe. This filename may also be coded as base64 or quoted-printable. 10.Skipped file name If file extension is not present MUA may generate file name and extension based on MIME type. For example if Content-type=application/hta Outlook express will name file like ATT00xxx.hta (reported by Aidan O'Kelly ) 11.Endless UUEncode messages UUEncode part usually ends with ` end As it was pointed by Funk Gabor <Funk.Gabor@hunetkft.hu> at least Outlook Express decodes uuencoded part which doesn't have this terminators while multiple filters skips these parts. 12. Different filenames for Content-Type and Content-Disposition It's possible to make different filenames for Content-Type and Content-Disposition fields, for exaple Content-Type: text/plain; name=\"eicar.txt\" Content-Disposition: attachment; filename=\"eicar.com\" (found by eDvice Security). 13.Case sensitivity of Content-Type and Content-Disposition Most MUAs ignore case of Content-Type and Content-Disposition headres while content filtering software may behave in different way. It makes it possible to bypass content-filtering software by using header like CONTENT-type: text/plain; NAme=\"eicar.com\" 14.Additional dot in filename Windows agnores additional dot in the filename. That is name="eicar.com." is same with name="eicar.com" (reported by Edvice Security Services) 15.RFC 2231 encoding for filenames RFC 2231 allows next encoding chema for eicar.com: filename*1="eicar."; filename*2="com" which may not be recognized by content filter. (reported by David F. Skoll ) 16.Missed MIME-Version header It was reported by Martin O'Neal from Colsaire that Clearswift MAILsweeper fails to check attachment if MIME part misses MIME-Version header. Content filter should not rely on presence of MIME-Version and even Content-Type but should rely on message structure. 17.Incomlete encoding There may be different behavior of the target program and content-filter in case of incomlete encodings (for example with = sign in the middle of encoded stream for base64, incomlete quoted-printable numbers, incomplete uuencode strings, etc. (base64 problem reported by Ilya Teterin ) 18.Empty boundary boundary="" incorrectly parsed by multiple filters, but is correct boundary. (Stephane Lentz, Julian Field). 19.Corrupted MIME Non-stndard characters within MIME-encoded (e.g. space characters in BASE64 or non-printable characters) may be differently processed by client application and content filter. Reported by Hendrik Weimer. 20.MIME nesting Content filter may be bypassing by nesting multipart MIME parts. Reported by Hendrik Weimer. II. Bypassing detection of potentially dangerous content There is a lost of software that tries to detect and block or remove dangerous file content (HTML strippers, antiviral products, etc). Inability of this software to handle specific data makes it useless. 1. Inability to check Unicode content Multiple products (including Internet Explorer/Outlook Express) support Unicode (UCT-2, UTF-16) encoding for text formats including text/html. Unicode text begins with 0xFF 0xFE bytes (little endian) or 0xFE 0xFF bytes (big endian) with wide (WORD) characters. Content filtering software may fail to strip potentially dangerous information (scripts, ActiveX, etc) from Unicode format text. For example, "