Home page logo

bugtraq logo Bugtraq mailing list archives

SECURITY.NNOV: Bypassing content filtering software
Date: Fri, 15 Feb 2002 22:07:47 +0300


I  planed  to  release  this  advisory  later, but this problem actively
discussed  now  on  Bugtraq.  So,  I  decided to publish it, without any
information  on  vulnerable  products  (I have found few). Sorry for bad
English, please feel free to ask me if something is not clear. Of cause,
this advisory doesn't pretend to some kind of fullness, it's invented to
show  basic  approach  and targeted mostly on content filtering software
vendors.   I  will  be  grateful  for  information  on  actual  products

Original version of this article


There are common methods allowing to bypass almost any content filtering
software  (antiviral  products,  CVP firewalls, personal firewalls, mail
attachment filters, etc). I believe multiple products are vulnerable.


I.  Bypassing  attachment  detection  or invalid detection of attachment

  1. Encoded filename or boundary  in Content-Type/Content-Disposition
  2. Multiple  filename  or  boundary  fields  in  Content-Type       /
  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

II. Bypassing detection of potentially dangerous content

  1. Inability to check Unicode (UCT-2) content
  2. Inability to check UTF-7 content
  3. Inability to check file marked as UTF-7 Content

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.

I.  Bypassing  attachment  detection  or invalid detection of attachment

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

  Content-Type: application/binary; name="eicar.com"


 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?=

               name=eicar .com

 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


 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
 realization. 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

 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;=?us-ascii?B?;name="eicar.com";?=

 2. Multiple filenames/boundaries.

 Another  one  point  is  how software behaves if there multiple name or
 boundary attributes. Example:

  Content-Type: text/plain;

 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

  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

  5. MIME part inside MIME part

  This  bug  is  very  common  for software which strips attached files.

  Content-Type=application/exe; name="eicar.com"



  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


  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 <CR> without <LF> 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 <CR> without <LF>, see

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  encoding for text formats including text/html. Unicode (UCT-2)
 text  begins  with 0xFF 0xFE bytes with wide (WORD) characters in Intel
 host byteorder (less significant first). Content filtering software may
 fail to strip potentially dangerous information (scripts, ActiveX, etc)
 from  Unicode  format text. For example, "<script>" tag in unicode will
 be {'<', 0, 's', 0, 'c', 0, 'r', 0, 'i', 0, 'p', 0, 't', 0, '>', 0}
 2. Inability to check UTF-7 content

 Almost  any  MUA/Web  client  software support UTF-7/UTF-8 encoding for
 text.  Content  filtering  software may fail to strip dangerous content
 from  UTF-7/UTF-8  encoded  data. For example <script> tag in UTF-7 may
 look like <+AHM-+AGM-+AHI-+AGk-+AHA-+AHQ->.

 3. Inability to check content marked as UTF-7/UTF-8

 If  MUA  or  Web client retrieves UTF-7/UTF-8 encoded file this file is
 decoded  for  internal  processing, but not then saved to disk. That is
 text  "<+AHM-+AGM-+AHI-+AGk-+AHA-+AHQ->"  will be used as "<script>" in
 Internet  Explorer itself, but if this text is in attached file it will
 be saved without changes.

 It  may be possible to fool software into thinking attached file should
 be decoded, while it shouldn't.

 For example,

 Content-Type: text/html;

 shouldn't  be  decoded from utf-7 before checking it's content, because
 it will be saved by Internet Explorer (or MUA) as is.

 I  believe  for  content  marked  as  utf-7/utf-8  both decoded and not
 decoded content should be checked.

III. What should be done?

 1. What client software vendor should do.

  Client  software behavior should be as predictive as it possible. Even
  small  problems  (like  null  bytes  and  unsafe  fgets())  should  be
  corrected.  Configuration  options  to  block  dangerous  content (for
  example   files   with   specified  extensions).  If  content  doesn't
  correspond to standards it's better ignore content rather then to make
  some  intuitive  decision about it. Behavior should as close to RFC as
  it  possible. Message with RFC violation shouldn't be processed (or at
  least user should be warned).
 2. What server software vendors should do.

  Check  all  possible situations with all known client software. Report
  all  bugs  found  (even  if it doesn't seem to be security related but
  looks  like  RFC  violation)  to  vendors.  Block content that doesn't
  conform  to  RFCs. Implement all possible encodings, but do not expect
  client software to support them always.

 3. What system administrators should do.

  Never  believe  you  system  is  protected against malware. Always
  build your network having in mind possibility of intrusion. Protect:
   Your users:
    Have  a  written  instruction  and  signed  acceptable  usage policy
    agreements.  Instruct  your  users  on  how to deal with potentially
    dangerous software.
   Your applications:
    Use    application    level   antiviral   products/firewalls.  Only
    application  level  antiviral  products  (for  example antivirus for
    Outlook  or for MS Office) can block malware by it's behavior rather
    then signature. It allows to catch almost any malware.
   Your workstations:
    It's  not  enough  to  protect  servers. It's very important to also
    protect  your workstations. Even if your server software will miss a
    virus  in e-mail it may be caught on workstation than it will try to


        { , . }     |\
+--oQQo->{ ^ }<-----+ \
|  ZARAZA  U  3APA3A   }
+-------------o66o--+ /
You know my name - look up my number (The Beatles)

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]