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 link

Starred by 3 users

Issue metadata

Status: Fixed
Buried. Ping if important.
Closed: Feb 2014
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug-Security

Sign in to add a comment

Security: UXSS via dispatchEvent on iframes (subject to some conditions)

Reported by, Feb 11 2014

Issue description

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 ", new CustomEvent('click'));".
I don't have the knowledge to suggest a code patch.

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)

 - 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
   - child.html is at http://localhost:8000/child.html
 - Open
 - Observe "Stolen: stylesheet=ayti; CHILD_SECRET"
 - Note that the CHILD_SECRET cookie should be inaccessible from the parent page.

1.1 KB View Download
1.1 KB View Download

Comment 1 by, 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:
    document.cookie = 'CHILD_SECRET';
    window.addEventListener('click', function (e) {
      var _tmp = e.type;
      return document.querySelector('.click-handler');
    }, false);

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'.
    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'));
    var eh = new MyEvtHandler();
    window.addEventListener('click', eh.handler.bind(eh), false);

    if (!haveGot) {
      haveGot = true;
      x = getType.caller
      x.bind({utility: function (elt) { = elt}})({})
      // DOM element now stored in

Apologies if this should've gone in an attachment.

Comment 2 by, Feb 11 2014

Labels: Cr-Blink
Status: Available
Mike, could you please help triaging this bug?

Comment 3 by, Feb 11 2014

Labels: Security_Severity-Low

Comment 4 by, 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, Feb 12 2014

Actually attach the file.
2.4 KB View Download
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, Feb 12 2014

Sure.  @mkwst: Feel free to reassign to me.
Project Member

Comment 8 by ClusterFuzz, Feb 12 2014

Labels: Pri-1

Comment 9 by, Feb 12 2014

I put up 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?
Status: Fixed
Project Member

Comment 13 by ClusterFuzz, 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

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, 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, Feb 19 2014

Labels: -M-32 -Merge-Triage -M-34 Merge-Requested
Merge requested for M33

Comment 17 by, 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, Mar 5 2014

Labels: -Merge-Approved merge-merged-1750
The following revision refers to this bug:

r168445 | | 2014-03-05T07:53:48.762432Z

Changed paths:

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

> Add cross-origin BindingsSecurity checks to 'EventTarget::dispatchEvent'.
> BUG= 342618 
> Review URL:

Review URL:
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!
Project Member

Comment 28 by ClusterFuzz, May 21 2014

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

Comment 29 by ClusterFuzz, Feb 2 2016

Labels: -Security_Impact-Beta
Project Member

Comment 30 by, Oct 1 2016

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

For more details visit - Your friendly Sheriffbot
Project Member

Comment 31 by, Oct 2 2016

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

For more details visit - Your friendly Sheriffbot
Labels: allpublic
Labels: CVE_description-submitted

Sign in to add a comment