[24300] in bugtraq
Non existing attachments, more info
daemon@ATHENA.MIT.EDU (Valentijn Sessink)
Sat Feb 16 13:46:25 2002
Date: Sat, 16 Feb 2002 12:36:05 +0100
From: Valentijn Sessink <valentyn+bugtraq@nospam.openoffice.nl>
To: bugtraq@securityfocus.com
Message-ID: <20020216123605.A30569@openoffice.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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
