Non existing attachments, more info

From: Valentijn Sessink (valentyn+bugtraqat_private)
Date: Sat Feb 16 2002 - 03:36:05 PST

  • Next message: 3APA3A: "SECURITY.NNOV: Bypassing content filtering software"

    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
    



    This archive was generated by hypermail 2b30 : Sat Feb 16 2002 - 10:23:14 PST