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
