Re: [websec] Minor feedback on draft-ietf-websec-mime-sniff-03

[Willy Tarreau <[e-mail]>]

On Sun, Jan 15, 2012 at 12:53:00PM -0800, Adam Barth wrote:
> On Sun, Jan 15, 2012 at 12:41 PM, Willy Tarreau <[e-mail]> wrote:
> > On Sun, Jan 15, 2012 at 11:52:38AM -0800, Adam Barth wrote:
> >> The requirement in the spec is what we intend.  The rule applies only
> >> to that exact octet sequence.
> >
> > But then what are the impacts of not matching the correct content-type ?
> 
> I'm not sure I understand your question.  Can you explain a scenario
> in which something happens that causes someone to be sad with the
> current requirements?

The draft presents an algorithm to determine a content type based on
available information, but ignores some important information such as
valid header values when presented in an unexpected form.

For instance, if I get a file advertised like this :

   Content-type: text/plain; charset=us-ascii

then it will not be interpreted as text/plain but rather based on what
is found in the contents. This can make it impossible to read some
documents purposely sent as plain text (eg: HTML or PS source code).

It could also also have security impacts such as causing some plugins
to be fed with the mis-identified data. For instance, imagine that I'm
browsing behind a filtering proxy which checks that PDF documents are
exempt of any exploit. This proxy will most likely consider the advertised
content-type and won't fire the PDF analyser on text/plain documents. But
the browser at the end of the chain ignores the text/plain and decides to
launch the plugin.

As you know, in general, having multiple components interprete different
things from similar contents is dangerous for interoperability and for
security.

Note that it is possible that I missed something as it's not trivial to
get right the way it's written :-/

Best regards,
Willy