Last Comment Bug 294799 - Any_XPCOM_Object.anyFunction.__proto__.__parent__ refers to the invisible blank ChromeWindow
: Any_XPCOM_Object.anyFunction.__proto__.__parent__ refers to the invisible bla...
Status: RESOLVED FIXED
[sg:fix] -fixed by 294795. Bug detail...
: fixed-aviary1.0.5, fixed1.7.9
Product: Core
Classification: Components
Component: Security (show other bugs)
: Trunk
: x86 Windows XP
: -- normal (vote)
: ---
Assigned To: Johnny Stenback (:jst, jst@mozilla.com)
:
: David Keeler [:keeler] (use needinfo?)
Mentors:
Depends on: 294795
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-19 08:20 PDT by moz_bug_r_a4
Modified: 2007-04-01 15:05 PDT (History)
9 users (show)
dveditz: blocking‑aviary1.0.5+
dveditz: blocking1.8b3+
dveditz: blocking‑aviary1.5+
bob: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (179 bytes, text/html)
2005-05-19 08:28 PDT, moz_bug_r_a4
no flags Details
window.blur.__proto__.__parent__.open() (240 bytes, text/html)
2005-05-31 18:01 PDT, moz_bug_r_a4
no flags Details
arbitrary code execution with Adblock (170 bytes, text/html)
2005-05-31 18:04 PDT, moz_bug_r_a4
no flags Details

Description moz_bug_r_a4 2005-05-19 08:20:02 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

Any_XPCOM_Object.anyFunction.__proto__.__parent__ refers to the invisible blank
ChromeWindow. It is [object ChromeWindow], but its location is "about:blank".
thus, it does *not* have chrome privilege.

There is a exception:
document.open.__proto__.__parent__ refers to document.defaultView


I'm not sure what an attacker can do. but, at least this bug can be used in
order to circumvent the built-in popup blocker.

  window.alert.__proto__.__parent__.location =
    "javascript:window.open('http://www.mozilla.org/')";


Affected:
(Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
(Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050518 Firefox/1.0+

(Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
(Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050518

(Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Thunderbird/1.0.2
(Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050518 Thunderbird/1.0.4
(Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050518 Thunderbird/1.0+

Note for Thunderbird:
Content script cannot change ChromeWindow.location and cannot call
ChromeWindow.open()


Note:
Firefox and Thunderbird have critical issue that is similar to this bug.
see Bug 294795.


Reproducible: Always

Steps to Reproduce:
Comment 1 moz_bug_r_a4 2005-05-19 08:28:07 PDT
Created attachment 184008 [details]
testcase
Comment 2 moz_bug_r_a4 2005-05-19 08:43:01 PDT
Sorry, I've tested this testcase with local file (file://). Web pages
cannot change ChromeWindow.location.
Comment 3 moz_bug_r_a4 2005-05-20 02:09:11 PDT
I've made mistakes. 

When a page's url is https://, a page cannot change ChromeWindow.location.
But, when a page's url is http://, a page *can* change ChromeWindow.location.

testcase with http: url
http://members.tripod.com/cv6y-mlr8-9hh/ct7f-nm8q/open-test-2.html


And, this ChromeWindow is the nsIAppShellService.hiddenDOMWindow.
Comment 4 moz_bug_r_a4 2005-05-31 17:59:06 PDT
>When a page's url is https://, a page cannot change ChromeWindow.location.
>But, when a page's url is http://, a page *can* change ChromeWindow.location.

Sorry, this is incorrect. my old testcase is subject to same origin policy.
page A: http://a.a/a.html
page B: http://b.b/b.html
After page A changed hiddenDOMWindow.location, page B cannot access properties
of hiddenDOMWindow.

Content window can call directly hiddenDOMWindow.open(), without side effect.
  window.blur.__proto__.__parent__.open('http://www.mozilla.org/');

Also, the following is possible. (w.opener is hiddenDOMWindow)
  w = window.open.__proto__('http://www.mozilla.org/');


If user installed Adblock, this bug allows an attacker to run arbitrary code.
If Adblock is installed, hiddenDOMWindow contains Adblock's component. and
content window can use functions of Adblock's component.

------
Target code from adblock.jar!/content/component.js:
  function adblockRemoveSlow(node, wnd, immediate, removalCode) {
  	// use timeout to collapse node - otherwise the reflow-queue doesn't catch it
  	// set style + collapse frameset-cols+rows for frames (if specified)
  	if (immediate) (removalCode) ? eval(removalCode) : (node.style.display = "none");
  	else {
  		var nodeIndex = adblockNodeIndex(wnd, node);
  		wnd.setTimeout(
  				"var node = window._AdblockObjects["+nodeIndex+"];\
  				"+  (removalCode ? removalCode : "node.style.display = 'none';")  +"\
  				delete window._AdblockObjects["+nodeIndex+"];", 0); // no content will be
loaded
  	}
  }

Exploit code:
  var code = "alert(location.href + '\\n\\n' + Components.stack);";
  window.blur.__proto__.__parent__
  .adblockRemoveSlow(null, window, false, code);
------

The string passed as the first argument of |wnd.setTimeout| is evaluated in
the context of |wnd|, but it is evaluated with the principal of caller
(adblockRemoveSlow) that has chrome privilege.

I've confirmed that this exploit code works on:
Adblock 0.5.2.039 + Firefox/1.0.4 
Adblock 0.5.2.039 + Firefox/1.0+ (2005-05-31-13)
Adblock 0.5.2.039 + Mozilla/1.7.8
Comment 5 moz_bug_r_a4 2005-05-31 18:01:29 PDT
Created attachment 184972 [details]
window.blur.__proto__.__parent__.open()
Comment 6 moz_bug_r_a4 2005-05-31 18:04:06 PDT
Created attachment 184973 [details]
arbitrary code execution with Adblock

This requires Adblock installed.
Comment 7 moz_bug_r_a4 2005-06-13 05:53:31 PDT
I guess this should not be made public, until Bug 297543 is resolved.
Comment 8 Johnny Stenback (:jst, jst@mozilla.com) 2005-06-15 23:20:37 PDT
Marking FIXED now that bug 294795 is fixed.
Comment 9 Daniel Veditz [:dveditz] 2005-07-12 11:35:08 PDT
Adding distributors

Note You need to log in before you can comment on or make changes to this bug.