Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 7 users
Status: Fixed
Owner:
Closed: Jan 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Security



Sign in to add a comment
Security: Circumvent CSP Header restrictions via about:blank
Reported by gro...@gmail.com, Nov 28 2016 Back to list
This template is ONLY for reporting security bugs. If you are reporting a
Download Protection Bypass bug, please use the "Security - Download
Protection" template. For all other reports, please use a different
template.

Please READ THIS FAQ before filing a bug: https://www.chromium.org/Home
/chromium-security/security-faq

Please see the following link for instructions on filing security bugs:
http://www.chromium.org/Home/chromium-security/reporting-security-bugs

NOTE: Security bugs are normally made public once a fix has been widely
deployed.

VULNERABILITY DETAILS
Please provide a brief explanation of the security issue.

By loading a new document using window.open("","_blank") and document.write-ing into it, (being in about:blank) I can circumvent the CSP restrictions put on the document my js code was running on and reach out to other sites.
One could argue that the code was loaded with unsafe-inline in the CSP header, but that should still block any cross-site communication (e.g. 1x1px tracking image etc).
The about:blank page has the same origin as its loading document, but CSP restrictions have been removed.
I have seen there have been many issues around about:blank, but I have not found any reports just like this.

My tests show that Firefox does not show this behavior, but rather makes the new document inherit CSP from its loading document.

Here is a POC: https://grodum.org/csptest/hey.html


VERSION
Chrome Version: Version 54.0.2840.71 (64-bit) + [stable, beta, or dev]
Operating System: macosx 10.11.6 (15G1108)

REPRODUCTION CASE
Please include a demonstration of the security bug, such as an attached
HTML or binary file that reproduces the bug when loaded in Chrome. PLEASE
make the file as small as possible and remove any content not required to
demonstrate the bug.

Demo: https://grodum.org/csptest/hey.html


FOR CRASHES, PLEASE INCLUDE THE FOLLOWING ADDITIONAL INFORMATION
Type of crash: [tab, browser, etc.]
Crash State: [see link above: stack trace, registers, exception record]
Client ID (if relevant): [see link above]

 
Components: Blink>SecurityFeature
Comment 2 by gro...@gmail.com, Nov 28 2016
Mozilla is expicit about it here: https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy

Content from about:blank and javascript: URLs inherits the origin from the document that loaded the URL, since the URL itself does not give any information about the origin.
Labels: Security_Severity-Medium Security_Impact-Stable
Owner: mkwst@chromium.org
Status: Assigned
+mkwst - do you have thoughts on this? Tentatively assigning medium severity.
Labels: OS-All
Comment 5 by mkwst@chromium.org, Nov 29 2016
It surprises me that Chrome's not inheriting the policy; the spec is pretty explicit about it: https://w3c.github.io/webappsec-csp/#initialize-document-csp. Sounds like a bug in our implementation.
Comment 6 by mkwst@chromium.org, Nov 29 2016
Cc: jochen@chromium.org dcheng@chromium.org
https://codereview.chromium.org/2530343006 up for review.
Project Member Comment 7 by sheriffbot@chromium.org, Nov 29 2016
Labels: M-55
Project Member Comment 8 by sheriffbot@chromium.org, Nov 29 2016
Labels: Pri-1
Project Member Comment 9 by bugdroid1@chromium.org, Nov 30 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e598765e4822eac833a547abca92ce87a1287dc0

commit e598765e4822eac833a547abca92ce87a1287dc0
Author: mkwst <mkwst@chromium.org>
Date: Wed Nov 30 12:36:42 2016

CSP: "local schemes" should inherit policy when window.opened.

https://w3c.github.io/webappsec-csp/#initialize-document-csp mandates
that resources with "local schemes" ('data:', 'blob:', 'filesystem:',
'about:') inherit the policy of their opening context when opened via
things like 'window.open'. We're not doing that, but we ought to.

BUG= 669086 
R=jochen@chromium.org

Review-Url: https://codereview.chromium.org/2530343006
Cr-Commit-Position: refs/heads/master@{#435233}

[add] https://crrev.com/e598765e4822eac833a547abca92ce87a1287dc0/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/cascade/cross-origin-window-open.html
[add] https://crrev.com/e598765e4822eac833a547abca92ce87a1287dc0/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/cascade/cross-origin-with-own-policy-window-open.html
[add] https://crrev.com/e598765e4822eac833a547abca92ce87a1287dc0/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/cascade/same-origin-window-open.html
[add] https://crrev.com/e598765e4822eac833a547abca92ce87a1287dc0/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/cascade/same-origin-with-own-policy-window-open.html
[modify] https://crrev.com/e598765e4822eac833a547abca92ce87a1287dc0/third_party/WebKit/Source/core/dom/Document.cpp

Project Member Comment 10 by sheriffbot@chromium.org, Dec 13 2016
mkwst: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Any more changes expected here, or can we close as Fixed?
Project Member Comment 12 by sheriffbot@chromium.org, Dec 27 2016
mkwst: Uh oh! This issue still open and hasn't been updated in the last 28 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Status: Fixed
Marking as fixed, please re-open if that's not correct.
Project Member Comment 14 by sheriffbot@chromium.org, Jan 18 2017
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Labels: reward-topanel
Labels: -M-55 M-57
Labels: -reward-topanel reward-unpaid reward-1000
Nice find!  The panel decided to award $1,000 for this report.  A member of our finance team will be in touch shortly.

*** Boilerplate reminders! ***
Please do NOT publicly disclose details until a fix has been released to all our users. Early public disclosure may cancel the provisional reward. Also, please be considerate about disclosure when the bug affects a core library that may be used by other products. Please do NOT share this information with third parties who are not directly involved in fixing the bug. Doing so may cancel the provisional reward. Please be honest if you have already disclosed anything publicly or to third parties. Lastly, we understand that some of you are not interested in money. We offer the option to donate your reward to an established charity. If you prefer this option, let us know and we will also match your donation - subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing.
*********************************

Labels: -reward-unpaid reward-inprocess
Comment 20 by gro...@gmail.com, Jan 30 2017
Awesome, thanks!

Btw, I must say I am very impressed with your communication and transparency with me from the moment I reported to you testing and triaging, fixing and code-reviewing.
Having reported security issues to many other companies before (even other parts of G), you guys are certainly leaders the field and the way you handle security issues leaves me with confidence in Chrome.

Nicolai Grødum
Project Member Comment 21 by sheriffbot@chromium.org, Feb 3 2017
Labels: Merge-Request-57
Project Member Comment 22 by sheriffbot@chromium.org, Feb 3 2017
Labels: -Merge-Request-57 Hotlist-Merge-Approved Merge-Approved-57
Your change meets the bar and is auto-approved for M57. Please go ahead and merge the CL to branch 2987 manually. Please contact milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), ketakid@(cros), govind@(desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Please merge your change to M57 branch 2987 before 5:00 PM Pt, Monday (02/06/) so we can pick it up for next week Beta release. Thank you.
Please merge your change to M57 branch 2987 before 5:00 PM PT, Friday 02/10 (sooner the better please) so we can take it in for next week beta release. Thank you.
Cc: gov...@chromium.org
Labels: -Hotlist-Merge-Approved -Merge-Approved-57
I still don't think this needs to be merged. It's already in 57. Dropping the merge flags, CCing govind@ to confirm that I'm holding omahaproxy correctly. :)
M57 was branched at Chromium revision 444943 and cl listed at #23 https://chromium.googlesource.com/chromium/src/+/e598765e4822eac833a547abca92ce87a1287dc0 {#435233} so no merged is needed. Thank you mkwst@.
Comment 28 by mkwst@chromium.org, Feb 23 2017
Cc: jww@chromium.org mkwst@chromium.org
 Issue 511824  has been merged into this issue.
Labels: Release-0-57
Labels: -Release-0-57 Release-0-M57
Comment 31 Deleted
Labels: -CVE-2017-5029 CVE-2017-5033
Project Member Comment 33 by sheriffbot@chromium.org, Apr 26
Labels: -Restrict-View-SecurityNotify allpublic
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
Sign in to add a comment