New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 332023 link

Starred by 5 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Feb 2014
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Security
Nag



Sign in to add a comment

chrome allows POST requests with custom headers using flash + 307 redirect

Reported by netfuzz...@gmail.com, Jan 7 2014

Issue description

UserAgent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36

Steps to reproduce the problem:
1. first use burq suite as a proxy(interpect on)
2. Now go to netfuzzer.com/tuto.swf
3. see the post request is sent to netfuzzer.com/redirect.php that redirects the browser to google.com.br.
4. After the another post request with custom headers on google.com.br domain.

What is the expected behavior?

What went wrong?
chrome allowed send post requests with custom headers.

Did this work before? N/A 

Chrome version: 31.0.1650.63  Channel: stable
OS Version: 5.1 (Windows XP)
Flash Version: Shockwave Flash 11.9 r900
 
swf file source.
Tuto.as
398 bytes Download
Labels: Cr-Internals-Plugins-Flash
Owner: yzshen@chromium.org
Status: Untriaged
Yuzhu, it looks like we may be checking the header policy against the beginning of the redirect chain, rather than each link. Could you please take a look or reassign to the correct person?
Labels: -OS-Windows security Cr-Internals-Plugins-Pepper
Cc: raymes@chromium.org viettrungluu@chromium.org
Labels: -security
Cc: jsc...@chromium.org
I looked into the code and this seems to be what's happening:
----------------------------------------------------------
1) netfuzzer.com/tuto.swf triggers a call to PPB_Flash_Private.Navigate() with netfuzzer.com/redirect.php. It is a POST request with custom headers.

2) The request is handled by WebPluginContainerImpl::loadFrameRequest in the renderer. It navigates the tab to a new page (so Pepper/Flash is not involved thereafter). Eventually a URLRequest is created in the browser to send the request.

3) When the response (307) is received, it is forwarded to the renderer side. And then the renderer side decides to follow the redirect, so it sends a ResourceHostMsg_FollowRedirect to the browser.

4) The URLRequest follows the redirect to www.google.com.br with the original request headers, which include custom headers. Therefore, custom headers are sent to a different origin.
----------------------------------------------------------

I am not sure whether this is expected behavior or not. It doesn't seem harmful to me because we are not giving the response to a different origin. (But I am not a security expert.)

In any case, it doesn't seem to be a Flash or Pepper issue.


What do you think, Justin?
Odd. I just looked at it with NPAPI Flash on Firefox, and it discards the custom header on both the same-origin request and the redirect. That certainly seems preferable, but I can't find any documentation on why that would be correct.
It looks like the SWF at the server changed, because I' can't repro this anymore. Also, looking at the documentation, it appears that Flash has a header blacklist rather than a whitelist. So, as bad practice as this behavior is, it may be intentional.
 Issue 332245  has been merged into this issue.
Cc: alb...@gmail.com
@jschuh: Hi, can you please cc me on  issue 332245  ?
Thanks for reply, Justin!

I cannot see 332245. Do you think we can close this issue or we should loop in someone who may have a better idea of the expected behavior in this case?
 Issue 332245  has been merged into this issue.
 Issue 332245  has been merged into this issue.
Cc: japhet@chromium.org
@yzshen - Well, just because it's intentional doesn't mean it isn't bad. HTML content explicitly disallows custom headers on cross-origin requests without a successful CORS preflight check. So, some sites rely on that guarantee to implement e.g. part of their XSRF protection strategy. Flash allowing this would undermine mechanisms like that.

@japhet - Are we sure we're doing the right thing here from the loader's perspective (re: comment #5)?
If the load is entering blink as a request for a frame, then yes, we're doing the right thing. We don't have any CORS checks of any kind for frame loads. If I remember correctly, it would need to go through AssociatedURLLoader instead of WebPluginContainerImpl::loadFrameRequest to enable CORS checking.
 Issue 332245  has been merged into this issue.
can someone please cc me on this  bug 332245  ?

Comment 18 by jln@chromium.org, Jan 9 2014

Labels: Security_Severity-Medium
Project Member

Comment 19 by ClusterFuzz, Jan 9 2014

Labels: -Pri-2 Pri-1
Project Member

Comment 20 by ClusterFuzz, Jan 10 2014

Labels: Untriaged-1
Project Member

Comment 21 by ClusterFuzz, Jan 11 2014

Labels: -Untriaged-1 Untriaged-2
Cc: cpu@chromium.org
Cc: jecl...@adobe.com

Comment 24 by laforge@google.com, Jan 16 2014

Cc: smori...@adobe.com
Project Member

Comment 25 by ClusterFuzz, Jan 16 2014

Labels: -Untriaged-2 Untriaged-4
I am OOO until next Tuesday. But please let me know if we need to handle it earlier than that, I could arrange some time to work on it.

Just to confirm: Do we agree that the correct behavior is to remove all custom headers at the Pepper layer before we pass the request to blink for navigating the frame?
That means we will discard custom headers even if it is a same-origin request. But Justin has pointed out that it is what NPAPI Flash on Firefox does, so it shouldn't be a problem.

Either we remove the headers or we block requests with custom headers. My preference would be blocking the request, but that might break something.

Comment 28 by smori...@adobe.com, Jan 16 2014

Cc: xzh...@adobe.com

Comment 29 by xzh...@adobe.com, Jan 16 2014

I briefly tested it, Pepper flash is not involved in this redirect.

We just fixed a cross domain POST issue where the request sent by SWF content gets redirected by the server, and Pepper flash can now do security check on that.
Project Member

Comment 30 by ClusterFuzz, Jan 18 2014

Labels: -Untriaged-4 Untriaged-5
Project Member

Comment 31 by ClusterFuzz, Jan 21 2014

Labels: -Untriaged-5 Untriaged-6
Cc: abarth@chromium.org
+CC abarth

Hi, Adam. Would you please give us your suggestions? Thanks!

In short, currently when Flash gives Pepper a HTTP request to navigate the frame to a new URL, Pepper directly forwards the request to Blink. Both Pepper and Blink don't remove custom headers or abandon the request.

Do you think we should make a change to only allow certain headers? If yes, what is the whitelist? Do we use the "simple headers" definition from the CORS?

Yes, we should probably whitelist the simple headers from CORS.
Project Member

Comment 34 by ClusterFuzz, Jan 23 2014

Labels: -Untriaged-6 Untriaged-7
Status: Assigned
Project Member

Comment 36 by ClusterFuzz, Jan 23 2014

Labels: Missing_Impact-8
Labels: -Untriaged-7 -Missing_Impact-8 Security_Impact-Stable Security_Impact-Beta
Labels: OS-All
Project Member

Comment 39 by ClusterFuzz, Feb 1 2014

Labels: Nag
yzshen@: Uh oh! This issue is still open and hasn't been updated in the last 7 days. Since this is a serious security vulnerability, we want to make sure progress is happening. Can you update the bug with current status, and what, if anything, is blocking?

If you are not the right Owner for this bug, please find someone else to own it as soon as possible and remove yourself as Owner.

If the issue is already fixed or you are to unable to reproduce it, please close the bug. (And thanks for fixing the bug!).

These nags can be disabled by adding a 'WIP' label and an optional codereview link.

- Your friendly ClusterFuzz
Can this vulnerability be eligible for a bug bounty?
Possibly, but were you the original discoverer? Because we have an independent report forwarded from Mozilla that appears to predate your report.
yes, i am the discoverer. I used it to exploit a vulnerability on mozilla's bugzilla, then they reported here. is there any problem on it?
Labels: reward-topanel
No, there's no problem. We just need to make sure the first report is credited. So, it sounds like this is eligible, but that's not a guarantee, as the panel still needs to review it.
It's ok then. Is this fixed on dev release?
No, the bug status has not been changed to "Fixed" and there's no update showing the CL was committed.
Project Member

Comment 47 by bugdroid1@chromium.org, Feb 5 2014

------------------------------------------------------------------------
r249114 | yzshen@chromium.org | 2014-02-05T21:38:17.813719Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/tools/metrics/histograms/histograms.xml?r1=249114&r2=249113&pathrev=249114
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/renderer/pepper/pepper_flash_renderer_host.cc?r1=249114&r2=249113&pathrev=249114

PPB_Flash.Navigate(): Disallow certain HTTP request headers.

With this CL, PPB_Flash.Navigate() fails the operation with
PP_ERROR_NOACCESS if the request headers contain non-simple headers.

BUG= 332023 
TEST=None

Review URL: https://codereview.chromium.org/136393004
------------------------------------------------------------------------

Comment 48 by jecl...@adobe.com, Feb 8 2014

Cc: dwrod...@adobe.com akap...@adobe.com
Project Member

Comment 49 by ClusterFuzz, Feb 9 2014

yzshen@: Uh oh! This issue is still open and hasn't been updated in the last 7 days. Since this is a serious security vulnerability, we want to make sure progress is happening. Can you update the bug with current status, and what, if anything, is blocking?

If you are not the right Owner for this bug, please find someone else to own it as soon as possible and remove yourself as Owner.

If the issue is already fixed or you are to unable to reproduce it, please close the bug. (And thanks for fixing the bug!).

These nags can be disabled by adding a 'WIP' label and an optional codereview link.

- Your friendly ClusterFuzz
Status: Fixed
So far, we've recorded 367k calls to PPB_Flash.Navigate, and only ~200 were rejected because of non-simple request headers.

So I think it is reasonable to restrict PPB_Flash.Navigate to only accept simple headers.

Closing the bug...
Project Member

Comment 51 by ClusterFuzz, Feb 13 2014

Labels: -Restrict-View-SecurityTeam M-33 Merge-Triage Restrict-View-SecurityNotify M-34
Adding Merge-Triage label for tracking purposes.

Once your fix had sufficient bake time (on canary, dev as appropriate), please nominate your fix for merge by adding the Merge-Requested label.

When your merge is approved by the release manager, please start merging with higher milestone label first. Make sure to re-request merge for every milestone in the label list. You can get branch information on omahaproxy.appspot.com.

Your fix is very close to the branch point. After the branch happens, please make sure to check if your fix is in.

- Your friendly ClusterFuzz
Cc: ihf@google.com
So, is there any updates about bug bounty? Is this eligible?

Comment 54 by dharani@google.com, Feb 19 2014

Labels: Merge-Requested
Merge Requested for 33 and 34.

Comment 55 by dharani@google.com, Feb 19 2014

Labels: -Merge-Triage

Comment 56 by dharani@google.com, Feb 19 2014

Labels: -M-34
The fix is already in M34. We need it only in M33.

Comment 57 by alb...@gmail.com, Feb 21 2014

Mozilla note: we can still reproduce the problem originally reported with the 33.0.1750.117 version released today using windows.

The fix is only in M34 and not the M33 released today
Cc: lafo...@chromium.org
+CC TPM of M33

Hi, Anthony. I noticed that Dharani has set the Merge-Requested flag. Would you please review this bug and fix for merge? Thanks!

Comment 59 by laforge@google.com, Feb 25 2014

Labels: -Merge-Requested Merge-Approved

Comment 60 by smori...@adobe.com, Feb 25 2014

Posting comment on behalf of Abhinav.
"There are some high profile video sites that are using headers for cookies and byte ranges. Some of these have not gone live yet, so any explorations for these may not return much traffic. 
 We need to make sure that these 2 header types are whitelisted and are not blocked by Chrome"

Hi, smoriwak.

I have replied to Abhinav about this in a separate mail thread several days ago. (Please let me know if you need to be CC-ed.)

I think Abhinav is okay with this.
Project Member

Comment 62 by bugdroid1@chromium.org, Feb 26 2014

Labels: -Merge-Approved merge-merged-1750
------------------------------------------------------------------------
r253298 | yzshen@chromium.org | 2014-02-26T00:11:41.757596Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1750/src/tools/metrics/histograms/histograms.xml?r1=253298&r2=253297&pathrev=253298
   M http://src.chromium.org/viewvc/chrome/branches/1750/src/chrome/renderer/pepper/pepper_flash_renderer_host.cc?r1=253298&r2=253297&pathrev=253298

Merge 249114 "PPB_Flash.Navigate(): Disallow certain HTTP reques..."

> PPB_Flash.Navigate(): Disallow certain HTTP request headers.
> 
> With this CL, PPB_Flash.Navigate() fails the operation with
> PP_ERROR_NOACCESS if the request headers contain non-simple headers.
> 
> BUG= 332023 
> TEST=None
> 
> Review URL: https://codereview.chromium.org/136393004

TBR=yzshen@chromium.org

Review URL: https://codereview.chromium.org/180653002
------------------------------------------------------------------------

Comment 63 by dharani@google.com, Feb 28 2014

Labels: Release-1-M33

Comment 64 by dharani@google.com, Feb 28 2014

Labels: CVE-2013-6666
Labels: -reward-topanel reward-unpaid reward-1000
Thanks for the report! This qualifies for a $1000 reward.
@mbarbella: Awesome! Thank you very much ! :)
Any updates about bounty payment? That's taking a good time to be done , what isn't very common here. Is it having any problem?
I'll chase it up for you. If you don't here back in a week or two with an update, feel free to email me directly. 
Any updates about bounty payment???????? Still don't get the bounty. Please give me some update, or explaination why that's taking so long. Don't understand what's going on here, google usually pays pretty quickly.

Labels: -reward-unpaid reward-inprocess
Lodged payment paperwork with finance team today. My apologies for the delay - this was my fault.
Labels: -reward-inprocess
Payment approved and on its way to you. Processing via our e-payment system can take up to 30 days.
Project Member

Comment 72 by ClusterFuzz, May 22 2014

Labels: -Restrict-View-SecurityNotify
Bulk update: removing view restriction from closed bugs.
Project Member

Comment 73 by ClusterFuzz, Feb 2 2016

Labels: -Security_Impact-Beta
Project Member

Comment 74 by sheriffbot@chromium.org, Oct 1 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member

Comment 75 by sheriffbot@chromium.org, Oct 2 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: allpublic
Labels: CVE_description-submitted

Sign in to add a comment