COMMAND

	Outlook may interpret mail headers

SYSTEMS AFFECTED

	Tested on : Outlook Express 5.5, 6.0

PROBLEM

	Valentijn Sessink [http://www.openoffice.nl] posted :
	

	original advisory at : http://www.openoffice.nl/special_interest/outlookbug.html

	

	

	When the message  contains  a  header  with  Carriage  Return  (0x0d  or
	<CR>) characters. Outlook incorrectly  interprets  these  as  end  of
	line (Carriage  Return/Line  Feed  combinations,  or  <CRLF>  as  per
	rfc2821/2822) delimiters.
	

	A message can be  formatted  so  that  Outlook  starts  parsing  message
	content prematurely. Outlook may even  read  attachments  that  are  not
	actually there. Thus, Outlook will see things that  a  content  scanning
	Mail Transfer Agent (MTA) does not scan for. This bug could  be  misused
	to send viruses to Outlook  users  behind  a  corporate  firewall.  Both
	UUencoded and MIME encoded attachment are affected by this bug.
	

	Example :
	

	A UUencoded attachment would simply use something like
	

	From: <001+outlookbug@nospam.blub.net>

	To: <billg@microsoft.com>

	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;FL@+2!H=\'1P.B\\O=W=W+F]P96YO9F9I8V4N;FPO<CR>end

	

	The content scanners I tested will not see this as  an  attachment,  but
	Outlook will.
	

	To send a MIME encoded attachment, you need to put  the  MIME  delimiter
	in the headers. Simply putting  the  \"Content-Type:\"  header  after  a
	carriage return is not enough, most scanners will catch that.
	

	 Update 

	 ======

	Firstly, my description of hiding  a  UUencoded  attachment  seemed  not
	100% correct: as far as I can see, Outlook needs a regular <CRLF>  at
	the end of a UUencoded attachment. Hiding the attachment in the  headers
	would thus look like:
	

	

	X-some-header: <CR><CR>begin  hiding.txt<CR>.....uuencoding....<CR>....<CRLF>

	`<CR>end<CR>

	

	

	So the last \"real\" line delimiter seems necessary (OE5.5/W95).
	

	

	A couple  of  people  seemed  to  think  that  simply  interpreting  all
	<CR>\'s with <CRLF>\'s  should  solve  the  issue,  however,  that
	makes things worse, as the scanner will now  be  forced  to  look  \"the
	outlook way\". Suppose a mail is formatted like this:
	

	

	From: <mailaddress> 

	To: <you>

	Subject: ...

	X-foo: X<CR><CR>begin  defeat scanner

	Content-Type: multipart/mime; delimiter.....

	

	

	Interpreting <CR> as <CRLF> will show  a  new  mail,  in  which  a
	broken UUencoded attachment shows  up.  However,  sensible  MUA\'s  will
	only see an \"X-foo\" header with a carriage return character  and  will
	continue to scan for headers, thus seeing a MIME encoded message.
	

	Further tricks with MIME in MIME and broken MIME  headers  inside  those
	MIME attachments could spell trouble too.
	

	A test where the MIME delimiter inside the body had a <CR>  in  front
	showed that Outlook Express 5.5 sees a MIME delimiter,  while  an  older
	Eudora version just showed a string of characters.
	

	Preliminary tests seem to show  a  nasty  interpretation  difference  in
	<CR><CR><LF>.  As  far  as  I  understood,  this  sequence   is
	sometimes added by some MIME encoding software and MTA\'s see  it  as  a
	single <CRLF>. OE5.5 seems to see this as  <CRLF><CRLF>  -  but
	further testing is required on this.
	

	Content scanners will - most likely - need to  make  several  passes  on
	the mail now, instead of - as they do now -  split  header  and  content
	and start parsing content. I hope that affected MUA\'s will get a  patch
	ASAP, as that makes the life of mail content  scanners  probably  a  lot
	easier.
	

	

SOLUTION

	None yet.
	

	Note :
	

	One could argue that a single <CR> should not  be  reproduced  by  an
	MTA,  as  it  is  illegal  to  send  a  bare  <CR>  -  per   RFC2821.
	Unfortunately, RFC2821 does not  specify  what  to  send  instead.  Both
	Postfix and Sendmail send bare <CR> on  output  -  other  MTA\'s  not
	tested. Having said that, Outlook is still  at  fault  interpreting  the
	result as an attachment.