[CrackMonkey] More fun with OE
bob at ruptured-duck.com
Sun Feb 17 19:10:42 PST 2002
I don't read bugtraq, but one of my far-flung correspondents does!
--- snip ---
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
Some additional information about the <CR> attachment hiding weakness
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:
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:
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.
Open Office NL
--- snip ---
More information about the Crackmonkey