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+outlookbugat_private> To: <billgat_private> 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 <mccholat_private> as they requested; then used <secureat_private> 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
This archive was generated by hypermail 2b30 : Wed Feb 13 2002 - 11:54:44 PST