Problem
Outlook Interprets Carriage Returns (0x0d or <CR>) as Carriage Return/Line
Feed combinations (0x0d 0x0a or <CRLF>) in Message Headers

Versions affected
Outlook Express 5.5 with Windows 95 and Outlook Express 6.0 on Windows 
2000 confirmed; other versions of Outlook and Outlook Express are 
suspected. Outlook Express on Macintosh seems unaffected (tested version 
5.02). No definite status on other MUA's here. I found no vulnerable
versions, but as I did not do extensive testing, it seems rather unwise to
mention a couple of brands and yell "probably not affected".

Symptoms
When you use Outlook, you may receive a message in which headers are
incorrectly interpreted as message data.

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

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

Please note that I tried a couple of content scanning MTA's but I did not
build a list of those, as that would be a rather time consuming task. Also,
I do not have any list of virus scanning companies so this would involve a
whole lot of Googleing around.

Further discussion
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.

Status
I sent this to Microsoft a couple of times. There has been no reply - not
even an acknowledgement. I sent it on January, 31, through a bug report form
on the Microsoft site. Then called Microsoft on February, 4, and sent the
bug report to <mcchol@microsoft.com> as they requested; then used
<secure@microsoft.com> on February, 7. I provided contact information,
offered help, and asked them to reply ASAP. I received nothing, not even an
acknowledgement.

In the mean time, I saw a discussion on the postfix-user mailinglist where
some viruses played tricks with <CR>'s in the headers. So the problem is "in
the wild".

History
My first attention was drawn by a virus that sent a long header starting
with "MIME-Version: 1.0^MContent-Type: multipart/related;". This was
January, 18. A Slashdot posting about the famous "begin  " bug made me test
out a couple of Outlook weaknesses; I remembered the "^M" posting and -
well, here it is.

Credits
Valentijn Sessink, Open Office <http://www.openoffice.nl>

This report is, in slightly modified form, also available on
http://www.openoffice.nl/special_interest/outlookbug.html

Oh, btw: nospam.openoffice.nl has an mx record, the mail address works.

Best regards,

Valentijn
-- 
Open Office - Linux for the desktop - www.openoffice.nl