1507909 - Firefox allows flash to follow 308 redirects to other origins with arbitrary content-types

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect, P2)

Description

[Shane Lester]

Description:
The Fetch specification and Cross-Origin Resource Sharing (CORS) severely restrict the headers that can be included in a cross-origin HTTP request (e.g., initiated through XMLHttpRequest) without triggering preflighting (i.e., an OPTIONS request). The idea is to allow only requests that could have been sent cross-origin before CORS existed (e.g., through an HTML <form> tag).

Adobe Flash is a known loophole to the cross-origin restrictions created by CORS. Flash uses its own cross-origin configuration mechanism, crossdomain.xml files, that existed prior to CORS. A known issue in Flash is that upon receiving an HTTP 307 or 308 redirect status code, Flash does not enforce crossdomain.xml files correctly.

Past bug submissions suggest that browsers work around this by blocking Flash from following these redirects. See for example, bug 1436241 which blocked 307 redirects. This bug is almost identical, just for 308 redirects instead.

Steps to reproduce:
Start Firefox.

Open the developer tools (F12) network tab.

Visit http://3-0-8.me:8000/csrf.htm which hosts a sample Flash file.

Allow Flash to run.

When the csrf.swf file runs, it sends a POST request to http://3-0-8.me:8000/ and encounters a 308 Permanent Redirect HTTP status code.

The 308 Redirect includes a cross-origin Location header to http://threeoheight.me:8000/info-display.htm

This POST request is sent to the new location. Were there any cookies in the 
browser previously set by threeoheight.me, they would have been sent with this request. Were threeoheight.me a site that uses cookies for authentication and relies on "Content-Type: application/json" being a non-simple request header to block CSRF attacks, this could allow the CSRF protection to be bypassed.

Only after the POST has already gone out does Flash check the crossdomain.xml to see if it should have been allowed.

Expected results:
Firefox should block Flash from following the 308 redirect similar to how 307s are handled (see, e.g., behavior on http://3-0-8.me:8000/csrf307.htm). Alternatively, Firefox or Flash could preflight the request or check the crossdomain.xml file first.

Version: 65.0a1 (2018-11-07) (64-bit)
Build ID 20181107100135
Flash: 31.0.0.122
OS: Fedora release 29 x86_64

Comment 1

[:Gijs (he/him)]

Paul, looks like you worked on bug 1436241, can you help triage this and/or find an assignee? Also, does this need to be hidden given the other bug is public?

(I would have pinged :qdot, but they're on PTO)

Comment 2

[Paul Theriault [:pauljt] (no longer reading bugmail)]

I don't really think this needs to be private, but that said, from a quick search, I couldn't see anywhere that explicitly references the 308 redirect (instead of 307) but that's probably just since 307 worked until recently. I do wonder about the safety of the check at nsPluginStreamListenerPeer.cpp line 680, if it only includes 307, and not 308 (but I dont know what the differences in behavior are). 

From a rating perspective, at worst I think this is sec-moderate[1]:
- On its own, this issue is not directly exploitable. Its only an issue for websites which rely on checking content-type in security decisions, which I'd argue is a security weakness in itself (though I know it exists).  
- From brief testing, Edge seems to not load the SWF[2], and IE11 allows the content-type to be set, same as Firefox. Qdot's comment [3] seems to indicate that Chrome 65 was vulnerable - not sure if that was the case here or not, but in any case Chrome 70 checks crossdomain.xml
- Flash click-to-play is also a small mitigation here (though not a strong one).  

All of that said, we've already fixed 307, hopefully a fix would be relatively simple, and would seem to be the safe (and correct?) thing to do. 

[1] I'm hesitant to contradict dveditz, my gut feel is that bug 1436241 is rated too severely 
[2] Not sure what's going on there, click-to-play doesn't fire on the abvoe URL
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1436241#c22
[4] IIRC there are other ways to set the content-type headers in IE, without needing flash. I might be wrong though.

Comment 3

[Paul Theriault [:pauljt] (no longer reading bugmail)]

Jim: the fix for this is likely super simple.  I.E. adding check for responseStatus == 308) in nsPluginStreamListenerPeer.cpp line 680. Assuming this doesn't break the web :) What do you think?

Comment 4

[Jim Mathies [:jimm]]

(In reply to Paul Theriault [:pauljt] from comment #3)
> Jim: the fix for this is likely super simple.  I.E. adding check for
> responseStatus == 308) in nsPluginStreamListenerPeer.cpp line 680. Assuming
> this doesn't break the web :) What do you think?

Maybe, I think flash does it's own networking in a number of cases so patching up the netowkr stuff we provide through the api may not mitigate. I'll try to find an owner to investigate.

Comment 5

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

BTW, I'm back and off PTO, but swamped on fission stuff so I'm not sure how quickly I could get to this.

Comment 6

[Shane Lester]

Hey, can I get a quick update on the status of this issue? I would like to publish a blog about leveraging 308 Redirects to achieve CSRF.