392459 - Ignoring "Content-Disposition: attachment" for plugins leads to XSS hazards

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, defect, P5)

Description

[Daniel Veditz [:dveditz]]

[e-mail] received the following from Yahoo:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[This note deals with an unpublished security flaw, if not in
Mozilla software then in someone else's software, so thoughtful
handling is appreciated.]

We noticed that FF (and some other browsers) ignore the
Content-Disposition header when making a request for a page
element (as opposed to populating a fresh document or
(i)frame).

For example, given a URL that returns a Flash object with a
Content-Disposition: attachment HTTP header, clicking on this
URL or using this URL as the src attribute of an (i)frame
triggers the download dialog, but using this URL within an
embed segment to load a Flash movie loads the content in the
browser rather than triggering the download dialog.  (Same is
true of images and presumably other content.)

Two questions:

  a) is this intentional and, if so, what is the rationale? [1]

  b) is there any mechanism for the server to tell FF that it
     must not render the response?

Since this behavior isn't unique to FF and user's don't
upgrade that quickly, we're taking a different approach,
but any insight you can provide would be quite helpful.

thanks!
Scott

[1] This behavior differs from IE (not that it's the paragon
    of secure behavior, mind you) and we did not find any
    relevant open or closed bugs discussing this exact topic
    (closest was 355332).

    Consider the case of a website that hosts user-supplied
    files, wants to allow authenticated users to download those
    files, but doesn't want those files rendered within its own
    domain (e.g., because they might introduce XSS flaws).
    We were hoping to use Content-Disposition: attachment for
    this as it allows us to use existing authentication
    mechanisms and is thus much simpler than redirecting to
    another domain (e.g., dotted-quad IP addr) with an alternate
    authentication mechanism (e.g., limited-duration signed
    URLs)

Comment 1

[Scott Renfro]

One correction, after further testing we noticed that IE does indeed behave the same way.


thanks,
Scott

Comment 2

[Mike Schroepfer]

Given comment 1 taking this off the blocking list for now.  Jesse/DVeditz adjust if that's wrong..

Comment 3

[Lucas Adamski [:ladamski]]

Marking sg:high as it can result in XSS for affected sites.  Also might be worth retesting in IE8 as they made some changes to content sniffing.

Comment 4

[Jesse Ruderman]

Nominating for blocking1.9.1: likely to be discovered independently, especially once we fix bug 474536 and issue an advisory for it.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Thing is, I think this behavior is interoperable across all browsers right now.  And changing it might well break sites.  :(

Comment 6

[Jesse Ruderman]

Hmm.  And how bad is it that plugin loads ignore content-disposition: attachment?

Comment 7

[Boris Zbarsky [:bzbarsky]]

Possibly bad, since plug-ins do stuff with the permissions of the site they're loaded from, basically...

I can probably live with adding a check for this for plugin loads specifically.

Comment 8

[Daniel Veditz [:dveditz]]

lowering to "moderate" on the grounds that it's not a problem particular to Firefox, and would only affect sites not aware of this cross-browser behavior.

It could be useful to treat plugins separately from other content (img, script, etc) since many plugins have complex security models of their own and function as sub-documents, more like iframes than simple components of the encompassing page.

Tangentially, there's discussion amongst plugin folks to add a way to let the plugin itself download its source rather than have the browser do it. Should that happen it could be a way to side-step the enforcement of Content-disposition requested by this bug.

Comment 9

[Johnny Stenback (:jst)]

Not going to hold the release on this sg:moderate bug, given that it's not specific to firefox, and it's been around for quite a while. Not to say we shouldn't fix it, but not holding the release.

Comment 10

[Josh Aas]

Does this still need to be hidden?

Comment 11

[John Schoenick [:johns]]

Attachment: Part 1 - WIP Don't load Content-Disposition: attachment streams as plugins or images in object/embed tags.

This doesn't actually fully work - we switch to type document and pass the channel to the URI loader, but we don't reach the download-dialog handler for some reason.

Comment 12

[John Schoenick [:johns]]

Attachment: Part 2 - For plugins that spawn before their stream, reject streams with attachment content disposition

Comment 13

[John Schoenick [:johns]]

Attachment: Tests

Comment 14

[Jesse Ruderman]

http://miki.it/blog/2014/7/8/abusing-jsonp-with-rosetta-flash/ is a similar problem involving ignoring the MIME type. One of the suggested workarounds is to... use "Content-Disposition: attachment".

Comment 15

[John Schoenick [:johns]]

So the WIP version of these patches forced | Content-Disposition: | attachment to be loaded as a document, but unlike an iframe, <object> documents won't trigger a download prompt, so we either need to figure out how to fix that, or just refuse to load attachment disposition entirely. I'll un-bit-rot these and take a look

Comment 16

[John Schoenick [:johns]]

(In reply to Jesse Ruderman from comment #14)
> http://miki.it/blog/2014/7/8/abusing-jsonp-with-rosetta-flash/ is a similar
> problem involving ignoring the MIME type. One of the suggested workarounds
> is to... use "Content-Disposition: attachment".

Since this is being publicly discussed, should we open up this bug?

Comment 17

[Andrew McCreight [:mccr8]]

(In reply to John Schoenick [:johns] from comment #15)
> So the WIP version of these patches forced | Content-Disposition: |
> attachment to be loaded as a document, but unlike an iframe, <object>
> documents won't trigger a download prompt, so we either need to figure out
> how to fix that, or just refuse to load attachment disposition entirely.
> I'll un-bit-rot these and take a look

Boris, do you have an idea about the answer to this?

Comment 18

[Boris Zbarsky [:bzbarsky]]

You could just hand the channel off to nsIURILoader::OpenChannel, as long as you then forward along all the nsIStreamListener calls.  That should get you on the normal codepath used to dispatch content, an the Content-Disposition bits will then drop you into the external helper app service and whatnot.

On the other hand, I can't think of many cases where users would actually want such a dialog here.  So I think dropping things on the floor in the Content-Disposition:attachment case would also be ok.

Comment 19

[Marion Daly [:mdaly]]

:overholt, this bug hasn't been touched in 3 years, I'm making it a P5.

Comment 20

[Andrew Overholt [:overholt]]

I doubt it. qDot, do you know?

Comment 21

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

Tough to say. This bug comes from a different era when plugins did way more. We're down to flash now, so this /could/ be a problem if a site embedded user uploaded flash in an odd way, but that's gonna be a problem no matter what. I think we could take the "just drop it" choice from Comment 18 now with no real worries, it's just a question of if it's worth the work. I think that might be adaptable from the patches already on this bug.

Comment 22

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Do we still want/need to take any actions here? Is P5 the right priority for this?

Comment 23

[Boris Zbarsky [:bzbarsky]]

I think at this point the right thing is to continue to work on dropping Flash support, at which point this becomes moot. That's scheduled for fairly soon anyway, right?

Comment 24

[Neha Kochar [:neha]]

Wontfix as Flash support is dropped already.