957403 - Flash: Cross-domain POST with custom headers allowed via 307 direct

Status: VERIFIED FIXED

(External Software Affecting Firefox Graveyard :: Flash (Adobe), defect)

Description

[Matt Wobensmith [:mwobensmith][:matt:]]

Attachment: ActionScript

It is possible to bypass cross-origin and crossdomain policy file rules for a POST that contains a custom header, by using a 307 redirect.

The issue is pretty much the same as bug 573873. This would be a regression of that bug. I'm testing in FP 11.9.900.170.

I haven't tested other types of redirects, so I can't say if they are affected or not.

This issue affects Chrome and Safari. I have not tested IE. Firefox detects the redirect and throws a dialog to block it. 

I've attached some sample code, but obviously this needs to be staged to see the behavior in action. I've also included a screen shot of Charles, which shows that the request for the (non-existent) policy file happens *after* the redirect has already occurred.

Comment 1

[Matt Wobensmith [:mwobensmith][:matt:]]

Attachment: Sample PHP redirect

Comment 2

[Matt Wobensmith [:mwobensmith][:matt:]]

Attachment: Charles_network_traffic.png

Comment 3

[Al Billings [:abillings - ex-MoCo]]

Adding Apple fellow as requested by Apple security.

Comment 4

[Benjamin Smedberg]

Jeromie, this one is for you.

Comment 5

[Jeromie Clark]

Thanks for the report.  This is Adobe 3690503.

Comment 6

[Jeffrey Czerniak]

Apple is tracking this as <rdar://problem/15779101>

Comment 7

[Daniel Veditz [:dveditz]]

Jeromie:

* does that mean Adobe confirms this as a Flash bug or just that you've entered it into your system?

* This was a pretty big deal in 2011 when browsers and Flash worked together to fix it (e.g. bug 573873). Was our testing faulty at the time or has this regressed in Flash. If the latter do you know what versions are broken?

* Any ETA for a fix? Is it being actively worked on?

Comment 8

[Jeromie Clark]

The bug is assigned and actively being worked on.  

Our understanding (confirmed through testing) is that this bug does not actually affect Firefox.  Firefox is overly strict in this scenario and strips custom headers from redirected HTTP requests regardless of whether or not they're permitted by the header policy file at the ultimate destination.  

Once we have a confirmed fix, we'll test it and identify an appropriate release vehicle.  Naturally, we're motivated and working diligently to provide an expedient and effective resolution.  Once we have a fix, we'll identify the earliest appropriate release vehicle for distributing the fix.

Our understanding based on my conversation with folks at Mozilla on Monday is that this is a responsible disclosure, and that we have no evidence that the issue is being actively exploited in the field.  We're also clear on the implications and trivial requirements for deploying same and are taking it very seriously.  If you see evidence that the situation has changed, please reach out to myself or the Adobe Product Security Incident Response Team (PSIRT) at <psirt at adobe dot com> with details, as it will very clearly inform how we approach releasing a fix.

Comment 9

[Daniel Veditz [:dveditz]]

(In reply to Jeromie Clark from comment #8)
> Our understanding (confirmed through testing) is that this bug does not
> actually affect Firefox.  Firefox is overly strict in this scenario and
> strips custom headers from redirected HTTP requests regardless of whether or
> not they're permitted by the header policy file at the ultimate destination.

That's what I saw in my primary profile, but when I tried using a "fresh" Firefox profile the exploit did its thing with no trouble. I've cc'd you on the bug where this problem was reported to us. Using the STR from bug 953105 comment 4 you can check it out. The summary changes "I" made on 2014-01-14 (see bug's history) were using Firefox:
https://landfill.bugzilla.org/bugzilla-tip/show_activity.cgi?id=17039
 
> Our understanding based on my conversation with folks at Mozilla on Monday
> is that this is a responsible disclosure,

So far. Mario has also reported it to Chrome so hopefully you're working with them, too.

> and that we have no evidence that
> the issue is being actively exploited in the field.

True as far as we know. However this issue got a fair amount of coverage in 2011 before it was fixed at that time and there may be other folks like Mario who have re-discovered it.

Comment 10

[Jeromie Clark]

Yeah, I just caught that from reading 953105.  We'll look into it more deeply. 

I'm not comfortable talking about our engagement with other partners in a public forum.  Please be assured that we'll take appropriate and diligent action and involve partners as necessary.  I'd be more than happy to share details with you under NDA (my understanding is that we already have an NDA with Mozilla) if you'd like to talk about it.  Feel free to email me directly for contact info.

Comment 11

[Daniel Veditz [:dveditz]]

There was another unscheduled Flash update today (12.0.0.70). Does this release have a fix for this bug? If not is there any update you can share about progress on fixing this bug?

Comment 12

[Jeromie Clark]

Again, I'm not comfortable talking about our engagements with other partners in a public forum.  The resolution to this issue is ultimately not within our control, and all major players are aware of the issue and the steps required for mitigation. As organizational cultures are unique, we have more information about the status from some partners vs. others.

As I offered in the original response, I'm more than happy to share details under NDA.  Feel free to reach out via email to coordinate the logistics.

Comment 13

[Jeromie Clark]

Also, the bugs that were opened with other vendors should reflect the current status on those platforms.

Comment 14

[Frédéric Buclin]

What's the status of this bug? It looks like Chrome fixed this problem almost a year ago, see https://code.google.com/p/chromium/issues/detail?id=332023. Also, [e-mail] asked in https://code.google.com/p/chromium/issues/detail?id=332245#c4 to be CC'ed to this bug. Is this ok?

Comment 15

[Gervase Markham [:gerv]]

Jeromie: are you able to give us a status update?

Gerv

Comment 16

[Jeromie Clark]

The outstanding is on Safari, which isn't sending NPN_URL_Redirect_Notify.  I reported it in a timely manner when this came in, and have repeatedly tried to escalate this with them.  I continue remind them about it periodically, but there's no visible progress and no comment beyond receipt of our communication.  It's unfortunate.

Comment 17

[Jeromie Clark]

The outstanding issue is on Safari, which isn't sending NPN_URL_Redirect_Notify as needed.  I reported it in a timely manner when this came in, and have repeatedly tried to escalate this with them over the last ~16 months.  I continue remind them about it periodically, but there's no visible progress and no comment beyond receipt of our communication.  I'll continue to do what I can from my end, but it appears to have largely been ineffective to-date.  Feel free to share your thoughts on this with Apple as well.  Perhaps seeing wider interest from the browser community in getting this fixed might help justify the prioritization on their end.

Comment 18

[Gervase Markham [:gerv]]

dveditz: can we stop waiting for Safari here? They've had long enough...

Gerv

Comment 19

[Daniel Veditz [:dveditz]]

Yes, although I'm not sure what we're waiting to do at this point. Close this Flash bug as "fixed" for one, I suppose. Announce bug 953105 and tell people they need to take steps to discourage Safari visitors?

Comment 20

[Jeffrey Czerniak]

This will be addressed in Safari 9, which will be released tomorrow.

Comment 21

[Frédéric Buclin]

So Google Chrome fixed this bug 1.5 year ago, see comment 14, and Safari 9 has been released 2 weeks ago with a fix too, see comment 20.

Per comment 9, it seems Firefox is also affected, after all. dveditz, can you still reproduce this issue? If not, it looks like this bug can be closed. It would also be interesting to know which version of Flash contains this fix and if it has been backported to Flash 11.2 for Linux.

Comment 22

[Jeromie Clark]

It's been about a year since we fixed this in Flash, so it would probably be prudent to test these again, just to be sure that nothing was injected between now and then.  We should also look at 64-bit Firefox on Windows, which wasn't really a relevant target at the time.  

Adobe is shut down through January 4th, and we'll have stragglers coming back the following week.  I can't really do much from this side between now and then.  I'd be happy to look at it when we're all back in the office.

Comment 23

[Daniel Veditz [:dveditz]]

punting request to Matt who has(had) a server setup to test this.

Comment 24

[Matt Wobensmith [:mwobensmith][:matt:]]

This was not an issue for Firefox, as I mentioned in the original report.

I've verified that Flash Player 20,0,0,267 in Firefox 43.0.4 - as well as latest Safari and Chrome - no longer redirects to the cross-domain resource. 

I also checked the latest release version of Firefox 64-bit on Windows, and it's fine there as well.

Comment 25

[BMO Automation]

Version and milestone values are being reset to defaults as part of product refactoring.