Subject: [websec] Video and audio types added to draft-ietf-websec-mime-sniff

From: Adam Barth <[email-masked]>
Date: Mon, 24 Jan 2011 14:35:30 -0800

Websecians,

I've uploaded a new draft of draft-ietf-websec-mime-sniff that
contains a handful of signatures for video and audio types supported
by web browsers:

http://www.ietf.org/id/draft-ietf-websec-mime-sniff-01.txt

I've been trying to avoid getting embroiled in the video/audio format
mess, but several folks have asked me to add this information to the
document so that browsers can improve their interoperability.

As you can see, I've added WebP, Ogg, WAVE, and WebM:

http://tools.ietf.org//rfcdiff?url1=http%3A//www.ietf.org/id/draft-ietf-websec-mime-sniff-00.txt&url2=http%3A//www.ietf.org/id/draft-ietf-websec-mime-sniff-01.txt

I would like to add MP3 and H.264 as well, but I'm unsure which
signatures to use.  If you know which signatures we should use for
these formats, please let me know.  Also, note that
http://www.w3.org/html/wg/wiki/ChangeProposals/NoVideoContentType will
likely have an effect on how we'll want to treat sniffing video,
depending on whether that change proposal prevails.

Thanks,
Adam

---

From: Tobias Gondrom <[email-masked]>
Date: Tue, 25 Jan 2011 19:15:48 +0000

Hello Adam, hello fellow websec members,

thanks a lot for the new version.
Just been reading through your draft again and have a few questions and
comments (as an individual, not in my WG chair role):

0. unfortunately don't know too much about video format sniffing, so
hope someone else can help with MP3 and H.264?

1. in section 2, page 5: a note states: "If an HTTP response contains
multiple Content-Type header fields, the user agent MUST use the
textually last Content-Type header field to the official-type.For
example, if the last Content-Type header field contains the value "foo",
then there is no official media type because "foo" cannot be interpreted
as a media type (even if the HTTP response contains another Content-Type
header field that could be interpreted as a media type)."
Question: Does this derive from a requirement in RFC2616 or is this your
recommendation and if the latter why can't a user agent use a
content-type he supports?

2. And regarding Mime-sniffing when a content-type is set:
Although rfc2616 states that mime-types may only be guessed by a
recipient, do you know whether common browser implementations guess the
mime-type even when the content-type is given (I believe to remember to
have run into this in some windows scenarios when the browser read the
content-type and handed the data over to the OS for display and the OS
then determined a different media-type (using magic numbers,
filename-extensions, etc.) and again opened a totally different
application. Are you aware whether this is still true?
(RFC2616, section 7.2.1 "Any HTTP/1.1 message containing an entity-body
SHOULD include a Content-Type header field defining the media type of
that body. If and only if the media type is not given by a Content-Type
field, the recipient MAY attempt to guess the media type via inspection
of its content and/or the name extension(s) of the URI used to identify
the resource. If the media type remains unknown, the recipient SHOULD
treat it as type "application/octet-stream".")

3. In section 5 I noticed that you classified postscript as "safe".
Am not sure whether this problem still exists, but I recall an instance
a few years back when I actually saw an attack using a postscript file,
that contained a script that would be executed on the server when the
file was rendered by a postscript library to another format (e.g. the
script then kicked in and started printing s.th.)
This flaw may not have been due to postscript, but only due to the
library, but am not sure that postscript specification doesn't contain
any scriptable content (file operations, printing) anymore?

and some more strategic questions:
4. What do you think, should we consider that a server be able to
declare in the http header that the client "MUST not" use mime-sniffing
and by this enforce a stricter mime-identification policy at the client?

5. And on another note, how do you think about different levels of
strictness (either to be set in the client and/or in the server (http
header): for example to illustrate this more, three levels:
a) disable mime-sniffing,
b) conservative mime-identification,
c) flexible mime identification.

6. and maybe stupid question:
In section 6: Why does svg+xml get a special treatment?
("If the official-type is "image/svg+xml", then let the sniffed-type be
the official-type (an XML type) and abort these steps.")

Many greetings

Tobias

On 01/24/2011 10:35 PM, Adam Barth wrote:
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec

---

From: Julian Reschke <[email-masked]>
Date: Tue, 25 Jan 2011 20:32:52 +0100

On 25.01.2011 20:15, Tobias Gondrom wrote:
> ...
> ...

Speaking for me, not Adam: this is not an RFC2616 requirement; a message 
that has multiple Content-Type headers is invalid per RFC 2616.

> ...

This is still true, but  AFAIK IE has improved.

> ...

See also: <http://tools.ietf.org/wg/httpbis/trac/ticket/155> and 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p3-payload-12.html#rfc.section.4.2>:

> 4.2 Representation Data
>
> The representation body associated with an HTTP message is either provided as the payload body of the message or referred to by the message semantics and the effective request URI. The representation data is in a format and encoding defined by the representation metadata header fields.
>
> The data type of the representation data is determined via the header fields Content-Type and Content-Encoding. These define a two-layer, ordered encoding model:
>
>   representation-data := Content-Encoding( Content-Type( bits ) )
>
> Content-Type specifies the media type of the underlying data, which defines both the data format and how that data SHOULD be processed by the recipient (within the scope of the request method semantics). Any HTTP/1.1 message containing a payload body SHOULD include a Content-Type header field defining the media type of the associated representation unless that metadata is unknown to the sender. If the Content-Type header field is not present, it indicates that the sender does not know the media type of the representation; recipients MAY either assume that the media type is "application/octet-stream" ([RFC2046], Section 4.5.1) or examine the content to determine its type.
>
> In practice, resource owners do not always properly configure their origin server to provide the correct Content-Type for a given representation, with the result that some clients will examine a response body's content and override the specified type. Clients that do so risk drawing incorrect conclusions, which might expose additional security risks (e.g., "privilege escalation"). Furthermore, it is impossible to determine the sender's intent by examining the data format: many data formats match multiple media types that differ only in processing semantics. Implementers are encouraged to provide a means of disabling such "content sniffing" when it is used.
>
> Content-Encoding is used to indicate any additional content codings applied to the data, usually for the purpose of data compression, that are a property of the representation. If Content-Encoding is not present, then there is no additional encoding beyond that defined by the Content-Type.

 > ...
> ...

The so-called "I mean it" header.. Google sends

   X-Content-Type-Options: nosniff

and I think IE respects that (just saying...).

> ...

Best regards, Julian

---

From: Adam Barth <[email-masked]>
Date: Tue, 25 Jan 2011 13:26:58 -0800

> that has multiple Content-Type headers is invalid per RFC 2616.

That's correct.  The intent of this document is to define a mapping
between HTTP responses and media types that user agents have the
option of using.  In addition to the entity-body, the mapping also
takes as input the HTTP headers that accompany the response.

It just so happens that the textually last Content-Type header field
gives better compatibility than using the textually first Content-Type
header field (I didn't try other possible rules).  More specifically,
we used to use the first one, got a bunch of complaints, switch to
using the last one, and no longer receive complaints.

> application. Are you aware whether this is still true?

Different browsers do different things in this regard.  IE is the most
permissive and willing to ignore many Content-Type header fields.
Safari next most permissive.  IMHO, both IE and Safari are too
permissive in this regard.  Chrome matches the spec exactly.  Firefox
is a stone's throw away from matching the spec.

> treat it as type "application/octet-stream".")

Right.  That's the problematic text that has relegated this topic to
the doldrums for so long.

> any scriptable content (file operations, printing) anymore?

Safe doesn't mean "vulnerability-free".  Safe means "does not run with
the origin's authority" care of draft-ietf-websec-origin.  Maybe we
should make that clearer?

> and I think IE respects that (just saying...).

Chrome also implements the X-Content-Type-Options header.  I think it
would be reasonably to describe its semantics in this document.  There
are some interesting cases that are worth writing down.  For example,
what does the user agent do when X-Content-Type-Options says "nosniff"
but there isn't a Content-Type header field?  This case wasn't
described in the original X-Content-Type-Options blog post.

> c) flexible mime identification.

The less complexity the better.  IMHO, we should have (a) disable
mime-sniffing and (b) follow the algorithm in this document.

> the official-type (an XML type) and abort these steps.")

Because that's what browsers do.  :)

The real reason has to do with how the <img> tag is implemented in
browsers.  SVG images are rendered by the same rendering engine used
by SVG documents, whereas other kinds of images (GIF, JPEG) are
rendered by the image decoding subsystem.  Most of the sniffing rules
described in Section 6 are contained in the image decoding subsystem,
which means SVG images bypass those rules.

Adam