Sign Up for Your FREE Weekly SecurityTracker E-mail Alert Summary
|
|
|
|
|
|
|
Put SecurityTracker Vulnerability Alerts on Your Web Site -- It's Free!
|
|
|
|
|
|
|
Want to learn about SecurityTracker? We've got answers to frequently asked questions right here
|
|
|
|
|
|
|
|
|
|
|
(Additional Details and Corrections are Provided) Re: Microsoft Outlook E-mail Client May Display Potentially Malicious File Attachments Illegally Embedded Within Mail Headers
|
Date: Feb 16 2002
|
Impact: Host/resource access via network
|
Exploit Included: Yes
|
Version(s): 5.5, 6.0; confirmed on Outlook Express 5.5 with Windows 95 and Outlook Express 6.0 on Windows 2000
|
Description: A potential vulnerability was reported in Microsoft's Outlook e-mail client. The software incorrectly interprets mail headers and
may present header-embedded attachments that contain malicious code and have bypassed content scanning engines.
In the original report, it was reported that Outlook incorrectly interprets Carriage Returns (0x0d or <CR>) contained in SMTP mail
headers as Carriage Return/Line Feed combinations (0x0d 0x0a or <CRLF>). As a result, an Outlook user may receive a message in which
headers are incorrectly interpreted as message data. A user may be presented with attachments that do not exist (in accordance with
RFC 822). It is reported that both UUencoded and MIME encoded attachments are affected by this bug.
The author of the original
report has clarified and corrected some details:
To hide a UUencoded attachment within the header so that Outlook will see the
attachment reportedly requires a regular <CRLF> at the end of the UUencoded attachment. So, the hidden attachment would look as
follows:
X-some-header: <CR><CR>begin hiding.txt<CR>.....uuencoding....<CR>....<CRLF>`<CR>end<CR>
|
Impact: A remote user may be able to send a mail message containing malicious code in the mail header such that the message will bypass content
filtering software and yet still be displayed as an attachment when received by another user using Outlook.
|
Solution: No solution was available at the time of this entry.
Innerdive Solutions,
Juniper
Networks,
Lantronix,
Lotus,
Lucent,
Marconi,
Microsoft,
Multinet,
Netscape,
NET-SNMP,
Nokia,
Novell,
Red Hat,
Redback
Networks,
SNMP Research
CERT has provided more information at the following URLs:
http://www.kb.cert.org/vuls/id/854306
http://www.kb.cert.org/vuls/id/107186
|
Vendor URL: www.microsoft.com/technet/security/ (Links to External Site)
|
Cause: State error
|
Underlying OS: Windows (Any)
|
Reported By: Valentijn Sessink <valentyn+bugtraq@nospam.openoffice.nl>
|
Message History:
This archive entry is a follow-up to the message listed below.
|
Source Message Contents
|
Date: Sat, 16 Feb 2002 12:36:05 +0100
From: Valentijn Sessink <valentyn+bugtraq@nospam.openoffice.nl>
Subject: Non existing attachments, more info
|
Hi all,
Some additional information about the <CR> attachment hiding weakness in OE.
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>....<CR
LF>
`<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.
Please note that the SecurityFocus bug information is not 100% correct. The
problem is not heavily exploited yet, but I have seen a few Badtrans
versions that at least tried to play with this feature.
Best regards,
Valentijn Sessink
Open Office NL
|
|
Go to the Top of This SecurityTracker Archive Page
|
