Non existing attachments, more info

[Valentijn Sessink <valentyn+bugtraq () nospam openoffice nl>]

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