Re: Re:[3] Corsaire Security Advisory - Multiple vendor MIME RFC2047 encoding issue

From: David Wilson (David.Wilson_at_isode.com)
Date: 09/27/04

  • Next message: Tracy Bost: "Re: Diebold Global Election Management System (GEMS) Backdoor Account Allows Authenticated Users to Modify Votes"
    To: "David F. Skoll" <dfs@roaringpenguin.com>
    Date: Mon, 27 Sep 2004 20:40:24 +0100
    
    

    > No, but you can make a version that is impossible to misinterpret
    > except by terminally buggy software. Besids, if any possible MIME
    > message can be ambiguous, as you imply, then the only safe action is
    > to discard every single MIME message, period.

    [snip]

    > The reformatting *must* eliminate the attack vector, because it *must*
    > force correctly-written software to interpret the message the same way
    > as the security agent. As I wrote before, if you contend that this is
    > impossible, then any MIME message at all is unsafe and must be discarded.

    A core problem in this area is that there is much software "out there"
    which DOES NOT interpret MIME messages according to the standards. The
    problem faced by software checking messages for attack vectors is that
    they should interpret the message not according to the standards but
    according to the misinterpretation of the standards by various broken
    software, or perhaps despite the standards.

    The first example I might quote relates to a buffer overflow
    vulnerability in Outlook Express, I think it was, a few years ago. An
    overlong Date: field in the header caused a classic buffer overflow.
    Now, I don't know the details, but it is possible that this could have
    worked even if the Date: field were correct according to RFC 2822. For
    instance, there could be a very long comment in the field.
    Canonicalization would not help here.

    The second example I would pick is how Microsoft UAs fail to heed the
    Content-type: text/plain field. They look at the data, and make
    assumptions about its contents. This is slightly different from the area
    of MIME ambiguities, but is another illustration of the problem faced by
    software whose aim is to check for potential security vulnerabilities.
    Correct MIME software treats text/plain as that, and would not think of,
    for instance, executing and HTML script found within.

    The third example relates to one of the Corsaire items. RFC 2047 makes
    it crystal clear that MIME encoded-words MUST NOT be used in MIME
    parameters, (I quote):

       + An 'encoded-word' MUST NOT be used in parameter of a MIME
         Content-Type or Content-Disposition field, or in any structured
         field body except within a 'comment' or 'phrase'.
     
    That does not stop software both generating such parameter values and
    interpreting them. While the example of the style (which I have seen):

      Content-disposition: attachment; filename==?us-ascii?Q?virus.exe?=

    is clearly syntactically wrong (unquoted tspecials in the value), there
    is nothing "wrong" with this:

       Content-disposition: attachment; filename="=?us-ascii?Q?virus.exe?="

    So this SHOULD be passed unchanged by a canonicalizer. But if the
    security software does not see the filename extension .exe, and relies
    on this for some test, and the UA DOES see .exe, then there is a
    problem.

    So, making sure the MIME message is in a form with a unique
    interpretation of the standards does not stop other software from
    misinterpreting the result.

    cheers

    -- 
    David Wilson <David.Wilson@isode.com>
    Isode Limited
    

  • Next message: Tracy Bost: "Re: Diebold Global Election Management System (GEMS) Backdoor Account Allows Authenticated Users to Modify Votes"