[CrackMonkey] Fwd: Non existing attachments, more info

[dep]

unlike others here, i neither sharpen my own teeth nor polish my own 
knob, but i thought that this might be of interest anyway.

----------  Forwarded Message  ----------

Subject: Non existing attachments, more info
Date: Sat, 16 Feb 2002 12:36:05 +0100
From: Valentijn Sessink <valentyn+bugtraq at nospam.openoffice.nl>
To: bugtraq at securityfocus.com

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

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

-------------------------------------------------------

-- 
dep

if you go with the flow you'll get
chopped to pieces by the turbines.