Vulnerability Development: Re: Plain text files in internet explorer

["Bernie Cosell" <bernie () fantasyfarm com>]

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