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

Issue 612132 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: May 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows
Pri: 1
Type: Bug-Security

Blocking:
issue 606651



Sign in to add a comment

Security: Bypass CORS check by reopening XHRs

Project Member Reported by hirosh...@chromium.org, May 16 2016

Issue description

VULNERABILITY DETAILS

RawResource::didAddClient() checks by |hasClient(c)| whether the client |c| is still valid after RawResourceClient::responseReceived() or so.

However, it is possible that, in responseReceived(), |c| is destructed and a new RawResourceClient |c2| is created at the same address of |c| and added as a client.
This is the case when XHR's open() is called inside the XHR's onerror() handler caused by a CORS check failure.

In such case, |hasClient(c)| after responseReceived() returns true and thus:
- responseReceived() is called for |c|, and
- dataReceived() and notifyFinished() for |c2| are called (without calling responseReceived()), which is wrong.
Because some CORS check is done in responseReceived(), |c2| bypasses CORS check and JavaScript can read contents of cross-origin requests that should be rejected by CORS protocol.

VERSION: I tested the following versions and found all affected:
- 50.0.2661.102 (Official Build) stable on Ubuntu
- 51.0.2704.47 (Official Build) beta on Ubuntu
- 51.0.2704.47 (Official Build) beta-m on Windows 7
- 52.0.2735.0 (Official Build) canary on Windows 7
- 52.0.2739.0 (Developer Build) on Ubuntu

REPRODUCTION CASE

1. Download the attached exploit.py
2. Run
   $ python exploit.py
3. Access http://localhost:8019/
4. Expected: You''get an alert "OK: XHRs failed correctly."
   Actual: You'll see an alert message with "NG: XHR succeeded unexpectedly with contents = <CONTENTS OF google.co.jp>".

 
exploit.py
1.4 KB View Download
A possible fix is, instead of comparing pointers of ResourceClient, give each occurrence of ResourceClient a unique sequence ID (unique ID is given for each addClient()) and compare both ResourceClient pointers and sequence IDs. I'm creating a draft CL (but not so sure whether it is mergeable to beta).

Comment 2 Deleted

|Resource::m_clients| is HashCountedSet, and Resource can have multiple occurrences of a client in |m_clients|, for example:
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/fetch/Resource.cpp&sq=package:chromium&l=408
If we should keep this behavior, it is hard to assign a sequence ID for each occurrences of ResourceClient.
Even if we can change this behavior (i.e. we can allow at most one occurrence of a client in |m_clients| and turn |m_clients| from HashCountedSet to HashSet), the changes would be larger and perhaps become not mergeable.

Another fix is to create WeakPtr<RawResourceClient> and use it in RawResource::didAddClient() to detect destruction of clients.
This will fix the test case in #0, but doesn't fix the cases such as:
- A client is removed and then re-added (without destruction of the client), or
- A non-Raw ResourceClient is removed, destructed, and re-created at the same address and re-added.
(I haven't found specific exploitable cases though)

japhet@, do you have any comments or suggestions?
Labels: Security_Severity-High Security_Impact-Stable
The fix was landed on 52.0.2741.0 and I confirmed the test case in Comment #0 works correctly on 52.0.2741.0 canary on Windows 7.
Labels: Merge-Request-51
The fix stayed for a day on canary. Requesting merge to M-51.

Comment 8 by tin...@google.com, May 20 2016

Labels: -Merge-Request-51 Merge-Review-51 Hotlist-Merge-Review
[Automated comment] Less than 2 weeks to go before stable on M51, manual review required.
Project Member

Comment 9 by ClusterFuzz, May 20 2016

Status: Fixed (was: Started)
Please mark security bugs as fixed as soon as the fix lands, and before requesting merges.

- Your friendly ClusterFuzz
Project Member

Comment 10 by sheriffbot@chromium.org, May 20 2016

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Cc: timwillis@chromium.org sshruthi@chromium.org
Labels: -Merge-Review-51 Merge-Approved-51
Approving merge to M51 branch 2704 based on comment #6 and #7. Please merge ASAP, latest before 5:00 PM PST Monday (05/23). Thank you.

+timwillis@ (security tpm) - just fyi 
Project Member

Comment 12 by bugdroid1@chromium.org, May 23 2016

Labels: -merge-approved-51 merge-merged-2704
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/da3930fa29674aaf2d3c0264f672171cc3fd7ef2

commit da3930fa29674aaf2d3c0264f672171cc3fd7ef2
Author: Hiroshige Hayashizaki <hiroshige@chromium.org>
Date: Mon May 23 05:09:38 2016

Check RawResourceClient destruction in RawResource::didAddClient()

BUG= 612132 

Review-Url: https://codereview.chromium.org/1986083002
Cr-Commit-Position: refs/heads/master@{#394331}
(cherry picked from commit 642f15021cf5907ffdc26d919b9870cd567caf89)

Review URL: https://codereview.chromium.org/2005743002 .

Cr-Commit-Position: refs/branch-heads/2704@{#633}
Cr-Branched-From: 6e53600def8f60d8c632fadc70d7c1939ccea347-refs/heads/master@{#386251}

[modify] https://crrev.com/da3930fa29674aaf2d3c0264f672171cc3fd7ef2/third_party/WebKit/Source/core/fetch/RawResource.cpp
[modify] https://crrev.com/da3930fa29674aaf2d3c0264f672171cc3fd7ef2/third_party/WebKit/Source/core/fetch/RawResource.h

Labels: Release-0-M51
Labels: Merge-Request-50
The fix is now included in the dev channel and I verified the test case works correctly on 2.0.2743.6 (Official Build) dev-m on Windows 7.

Requesting merge to M-50 because of Security_Impact-Stable label.
s/2.0.2743.6/42.0.2743.6/

Comment 16 by tin...@google.com, May 25 2016

Labels: -Merge-Request-50 Merge-Review-50
[Automated comment] Request affecting a post-stable build (M50), manual review required.
Affected URL: All.
Affected Resource type: Raw only (including XHRs).
Project Member

Comment 18 by sheriffbot@chromium.org, Aug 26 2016

Labels: -Restrict-View-SecurityNotify
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 19 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 20 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

Sign in to add a comment