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.
Issue 342618 Security: UXSS via dispatchEvent on iframes (subject to some conditions)
Starred by 2 users Reported by aidan...@gmail.com, Feb 11 2014 Back to list
Status: Fixed
Owner:
Closed: Feb 2014
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug-Security



Sign in to add a comment
VULNERABILITY DETAILS
Permits a page on an arbitrary site to retrieve the document element of any target page given the following conditions:
 - the target page may be embedded in an iframe
 - the target page has a handler for any window event
 - the target page gets or sets any property of the event in the handler (any jQuery listener)
 - the target page returns a dom node from the handler

The problem: dispatchEvent should complain when 'call'ed on iframe.contentWindow.
In child.html is a (somewhat) plausible example vulnerable site - it relies on the automatic conversion of event handler return values to true/false to detect whether an action was taken for an event.
This is exploited by calling the event handler directly (with a reference obtained from Function.prototype.caller) to obtain the dom node, giving me access to document.
I personally wasn't able to come up with an exploit without relying on the site returning a dom node in the event handler (the final condition).

Needs an additional test in blink/trunk/LayoutTests/http/tests/security/cross-frame-access-call.html for "window.dispatchEvent.call(targetWindow, new CustomEvent('click'));".
I don't have the knowledge to suggest a code patch.

VERSION
Chromium: Version 32.0.1700.102 Ubuntu 12.10 (32.0.1700.102-0ubuntu0.12.10.1~20140128.878.1)
Chrome: Version 32.0.1700.107 m (Windows 7 x64 SP1)

REPRODUCTION CASE
 - Download parent.html and child.html
 - Put them on two different web servers and edit the iframe src in parent.html
   to point to the location of child.html. I will assume that
   - parent.html is at http://127.0.0.1:8080/parent.html
   - child.html is at http://localhost:8000/child.html
 - Open http://127.0.0.1:8080/parent.html
 - Observe "Stolen: stylesheet=ayti; CHILD_SECRET"
 - Note that the CHILD_SECRET cookie should be inaccessible from the parent page.

FOR CRASHES, PLEASE INCLUDE THE FOLLOWING ADDITIONAL INFORMATION
N/A
 
parent.html
1.1 KB View Download
child.html
1.1 KB View Download
Comment 1 by aidan...@gmail.com, Feb 11 2014
Noticed a typo in parent.html - 'var t;' is unused.

To expand on child.html, it's mainly written to show how a real application might be vulnerable. A minimal case to work with parent.html would be:
  <script>
    document.cookie = 'CHILD_SECRET';
    window.addEventListener('click', function (e) {
      var _tmp = e.type;
      return document.querySelector('.click-handler');
    }, false);
  </script>

On the subject of 'real(ish) applications', an alternative vector of attack could be to (re)bind the event handler function if it contains references to 'this'.
e.g.
child.html:
  <script>
    MyEvtHandler = function () {
      this.utility = function (elt) { return elt.tagName; }
      this.handler = function (e) {
        var _tmp = e.type;
        var tag = this.utility(document.querySelector('.click-handler'));
        console.log(tag);
      }
    }
    var eh = new MyEvtHandler();
    window.addEventListener('click', eh.handler.bind(eh), false);
  </script>

parent.html:
  <script>
    [...]
    if (!haveGot) {
      haveGot = true;
      x = getType.caller
      x.bind({utility: function (elt) {window.aaa = elt}})({})
      // DOM element now stored in window.aaa
    }
    [...]
  </script>

Apologies if this should've gone in an attachment.
Comment 2 by jln@chromium.org, Feb 11 2014
Labels: Cr-Blink
Owner: mkwst@chromium.org
Status: Available
Mike, could you please help triaging this bug?
Comment 3 by jln@chromium.org, Feb 11 2014
Labels: Security_Severity-Low
Comment 4 by aidan...@gmail.com, Feb 12 2014
I think this is worse than I originally realised - the final condition is a stricter condition than the exploit requires.
The attachment shows how one can steal cookies from Google Drive (i.e. this is not just a hypothetical security flaw) - open the file, wait 5s, note document.cookie being alerted.
It wouldn't be hard to extend this to stealing documents.

To outline how this is done
 - The google docs JS sets up a generic handler on window for multiple events.
 - This generic handler calls a function (which calls another etc).
 - The event property 'get' happens about 3 calls deep into the child page.
 - We access the arguments for all of these functions via 'caller'.
 - We automate a traversal of any object arguments to find a DOM node, giving us document.

Note that the google doc itself is an empty spreadsheet and isn't specifically relevant to the exploit.
The problem itself is still the same - dispatchEvent should complain when 'call'ed on iframe.contentWindow.
Comment 5 by aidan...@gmail.com, Feb 12 2014
Actually attach the file.
docsxss.html
2.4 KB View Download
Cc: abarth@chromium.org tsepez@chromium.org
Labels: -Security_Severity-Low Security_Severity-High M-32 Security_Impact-Stable Security_Impact-Beta reward-topanel
Goodness me. Nice work.

@abarth: you've been pretty active at fixing serious cross-origin violations like these in the past. Interested?
Comment 7 by abarth@chromium.org, Feb 12 2014
Sure.  @mkwst: Feel free to reassign to me.
Project Member Comment 8 by clusterf...@chromium.org, Feb 12 2014
Labels: Pri-1
Comment 9 by mkwst@chromium.org, Feb 12 2014
Cc: jochen@chromium.org
I put up https://codereview.chromium.org/150203016/ as a quick fix. CCing Jochen for time-zone appropriate context.
Status: Started
Cool! That was fast. I wonder if there are any other properties like this where we have missing checks?
Project Member Comment 11 by bugdroid1@chromium.org, Feb 12 2014
The following revision refers to this bug:
    http://src.chromium.org/viewvc/blink?view=rev&rev=166999

------------------------------------------------------------------------
r166999 | mkwst@chromium.org | 2014-02-12T11:02:06.417947Z

Changed paths:
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/security/cross-frame-access-dispatchEvent.html?r1=166999&r2=166998&pathrev=166999
   M http://src.chromium.org/viewvc/blink/trunk/Source/bindings/scripts/code_generator_v8.pm?r1=166999&r2=166998&pathrev=166999
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/security/cross-frame-access-dispatchEvent-expected.txt?r1=166999&r2=166998&pathrev=166999

Add cross-origin BindingsSecurity checks to 'EventTarget::dispatchEvent'.

BUG= 342618 

Review URL: https://codereview.chromium.org/150203016
------------------------------------------------------------------------
Status: Fixed
Project Member Comment 13 by clusterf...@chromium.org, Feb 12 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
Comment 14 by aidan...@gmail.com, Feb 13 2014
On the subject of other missing checks, that's probably what I'm going to poke at next if you don't get(/haven't got) there first :)
@aidanphs: go for it! It'd be our pleasure to consider each bug for reward separately :)
Comment 16 by dharani@google.com, Feb 19 2014
Labels: -M-32 -Merge-Triage -M-34 Merge-Requested
Merge requested for M33
Comment 17 by laforge@google.com, Feb 25 2014
Labels: -Merge-Requested Merge-Approved
mkwst@ - can you please merge this to M33 ASAP? We have a release being cut tomorrow.
Project Member Comment 19 by bugdroid1@chromium.org, Mar 5 2014
Labels: -Merge-Approved merge-merged-1750
The following revision refers to this bug:
    http://src.chromium.org/viewvc/blink?view=rev&rev=168445

------------------------------------------------------------------------
r168445 | mkwst@chromium.org | 2014-03-05T07:53:48.762432Z

Changed paths:
   M http://src.chromium.org/viewvc/blink/branches/chromium/1750/Source/bindings/scripts/code_generator_v8.pm?r1=168445&r2=168444&pathrev=168445
   A http://src.chromium.org/viewvc/blink/branches/chromium/1750/LayoutTests/http/tests/security/cross-frame-access-dispatchEvent-expected.txt?r1=168445&r2=168444&pathrev=168445
   A http://src.chromium.org/viewvc/blink/branches/chromium/1750/LayoutTests/http/tests/security/cross-frame-access-dispatchEvent.html?r1=168445&r2=168444&pathrev=168445

Merge 166999 "Add cross-origin BindingsSecurity checks to 'Event..."

> Add cross-origin BindingsSecurity checks to 'EventTarget::dispatchEvent'.
> 
> BUG= 342618 
> 
> Review URL: https://codereview.chromium.org/150203016

TBR=mkwst@chromium.org

Review URL: https://codereview.chromium.org/187313004
------------------------------------------------------------------------
Labels: Release-2-M33
Labels: CVE-2014-1701
aidanphs - how would you like to be credited in our release notes? We'll go with "Credit to aidanphs" unless you tell us otherwise. Thanks.
aidanhs (minus the 'p') is my usual handle :)
Labels: -reward-topanel reward-unpaid reward-3000
My apologies for the delay here - $3000 for this one. I'll start the payment process today.
Labels: -reward-unpaid reward-inprocess
Labels: -reward-inprocess
Processing via our e-payment system can take a few weeks, but reward should be on its way to you. Thanks again for your help!
Thanks!
Project Member Comment 28 by clusterf...@chromium.org, May 21 2014
Labels: -Restrict-View-SecurityNotify
Bulk update: removing view restriction from closed bugs.
Project Member Comment 29 by clusterf...@chromium.org, Feb 2 2016
Labels: -Security_Impact-Beta
Project Member Comment 30 by sheriffbot@chromium.org, Oct 1
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 31 by sheriffbot@chromium.org, Oct 2
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