Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Bernie Cosell (bernie_at_fantasyfarm.com)
Date: Mon Sep 02 2002 - 12:25:07 CDT
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.
> 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
> 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
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
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*
-- Bernie Cosell Fantasy Farm Fibers mailto:berniefantasyfarm.com Pearisburg, VA --> Too many people, too few sheep <--