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:berniefantasyfarm.com     Pearisburg, VA
    -->  Too many people, too few sheep  <--          

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