Re: Plain text files in internet explorer

From: Bernie Cosell (bernie@fantasyfarm.com)
Date: 09/02/02 

From: "Bernie Cosell" <bernie@fantasyfarm.com>
To: vuln-dev@securityfocus.com
Date: Mon, 2 Sep 2002 13:25:07 -0400

On 2 Sep 2002, at 7:41, Dan Kaminsky wrote:

> >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?

> 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.

I guess folk could disagree on this... I think that the correct behavior
is to honor the MIME type and *NOT* try to second-guess the server.
Obviosly, YMMV...

> Importantly, I cannot concieve of a circumstance in which this can be
> described incorrect behavior. None.

As I say, YMMV. First, the hardwiring between 'extensions' and
underlying file types is, at best, idiosyncratic. Second, the *intent*
of the file types can vary.

> .. 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.

Yeah, but this is kind of silly, since at least 90% of the files loaded
are *NOT* loaded "via the address bar" but by HREFs, CSS's, SOURCE='s,
etc from *within* web pages. Nobody *sees* that the shockwave file came
down via a .swf or any other extension. it just "appears". The images on
a website largely just pop up, with the user not knowing or caring if
they were gif or jpeg or png files (and certainly not seeing the
extension-parts of the URLs that fetched them).

> 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.

Just so --- but depending on the "extension" doesn't seem like the right
solution, either. Associating the "type of a file" with its *name*
doesn't deal with the problem, really, either...

> I expect the exploit stream will eventually lead to MIME-type
> deprecation.

Actually, I think that what it ought to lead to is folks redoing their
'restrictions' so that they're [properly] based on the MIME types rather
than the coincidence of particular extensions. There *IS* a problem
here, but I think that keying on the *file*extension* just isn't the way
to deal with it. OS's *NEED* to have file type information, and this mis-
handling/confusion over MIME types is a _symptom_, rather than being the
disease, itself.

What I think is really happening here is that this is *ANOTHER*
drawback/vulnerability in Unix's simplistic "bag'o'bytes" model for
files, and having MIME types is the -right- thing to be doing. I think
that going even *farther* toward hardwiring "extensions" [which are both
arbitrary and ambiguous] into the larger scheme of things is a real
mistake. Overall, this kind of thing ought to be handled by *real*
resource/filetype information associated with the *FILE*, not with its
name or extension. For example, NTFS has all sorts of access-control
info associated with every file, why can't the info include its *actual*
type?

  /Bernie\ 

-- 
Bernie Cosell                     Fantasy Farm Fibers
mailto:bernie@fantasyfarm.com     Pearisburg, VA
    -->  Too many people, too few sheep  <--

Relevant Pages

  • Re: Mailing attachments
    ... >> You might want to ensure that file names have extensions, ... > Windows is when it comes to file associations. ... extensions and MIME types into things called Uniform Type Identifiers. ...
    (uk.comp.sys.mac)
  • Re: File types on RISC OS
    ... Beware your jingoism: extensions were just that initially: they were ... system meta data like RISC OS uses, just rather than being a 12 bit field ... fudged into some old data fields, it was three bytes that were free in the ... arbitrary meta-data can have MIME types attached to files. ...
    (comp.sys.acorn.misc)
  • Re: Is this a valid SEO link?
    ... should be done through HTTP headers. ... Google list extensions, but what it de facto means are MIME types, IMHO they just don't use "MIME type" to not scare away most of the homebreed webmasters. ...
    (alt.internet.search-engines)