OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Dan Kaminsky (dan_at_doxpara.com)
Date: Mon Sep 02 2002 - 00:41:04 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    >
    >
    >Is this actually specified someplace in some relevant RFC? I can't
    >comment on application/octet-stream, but I've never before heard that
    >text/plain was ambiguous. I thought it was crystal-clear and meant,
    >well, "plain text" [basically a sequence of characters in whatever
    >charset is specified].
    >
    >Is this interpretation some idiosyncracy of Microsoft's or is it actually
    >an RFC-supported 'correct' interpretation of the text/plain MIME type?
    >
    >
    Mozilla will occasionally render downloads from a scripted backend as
    plain text. It's really pretty annoying, correct behavior or not.

    All things being equal, I'll go with correct behavior being first that
    which matches what is presented to the user in the title bar, using
    standard (Microsoftian!) in-band filename notation, then if nothing
    usable is there, use the MIME-type as a hint. In such a circumstance:

    foobar.txt is always read as text.
    foobar.html is always read as html.
    foobar.php and foobar.php, which really *should* be foobar.html because
    -- dear god, they contain html -- can use the MIME-type to hint
    themselves into HTML parsing.
    foobar.gif is always read as gif.
    a javascript virus is always obviously either javascript(foo.js) or
    parsed as a gif(foo.gif).

    Importantly, I cannot concieve of a circumstance in which this can be
    described incorrect behavior. None. A link to foo.gif parsed as a
    Shockwave Flash executable is *always* misparsed, because the user chose
    to view the previous format, not the latter. GIFs can't exploit your
    system. Flash files can, just like any executable.

    We're seeing a reasonably steady stream of "x posing as y to get around
    z restriction" attacks made available specifically because filetype
    handling is being hidden behind a user-opaque format standard that
    places the type of a file far outside the file itself.

    I expect the exploit stream will eventually lead to MIME-type
    deprecation. But then, I also expect websites to stop exposing such an
    amazing amount of their database backend in their user-visible URLs, so
    maybe I'm being uncharacteristically optimistic.

    Yours Truly,

        Dan Kaminsky
        DoxPara Research
        http://www.doxpara.com