Last Comment Bug 289675 - getter/setter on window.__proto__.__proto__.__proto__ allows XSS attacks
: getter/setter on window.__proto__.__proto__.__proto__ allows XSS attacks
Status: RESOLVED FIXED
[sg:fix] Hold private until April 25,...
: fixed-aviary1.0.3, fixed1.7.7
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: Johnny Stenback (:jst, jst@mozilla.com)
: Hixie (not reading bugmail)
Mentors:
Depends on: 295606
Blocks: sbb+
  Show dependency treegraph
 
Reported: 2005-04-09 00:55 PDT by shutdown
Modified: 2007-04-01 14:38 PDT (History)
6 users (show)
dveditz: blocking1.7.7+
dveditz: blocking‑aviary1.0.3+
dveditz: blocking‑aviary1.5+
bob: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (1.24 KB, text/html)
2005-04-09 00:56 PDT, shutdown
no flags Details
Make context re-initialization work right again. (4.29 KB, patch)
2005-04-09 14:38 PDT, Johnny Stenback (:jst, jst@mozilla.com)
bzbarsky: review+
brendan: superreview+
chase: approval‑aviary1.0.3+
chase: approval1.7.7+
chase: approval1.8b2+
Details | Diff | Review
trunk version of what got checked in (4.17 KB, patch)
2005-04-21 11:35 PDT, Mike Connor [:mconnor]
no flags Details | Diff | Review

Description shutdown 2005-04-09 00:55:14 PDT
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2

Getter/setter defined on window.__proto__.__proto__.__proto__ is
executed when a global variable is used in scripts,
but is not cleared when a new page is loaded.
Therefore allows XSS attacks.
Testcase available.

Reproducible: Always

Steps to Reproduce:
1.define getter/setter on window.__proto__.__proto__.__proto__ with some name.
2.navigate the browser to the page that uses a global variable with a name 
defined in step 1.
Actual Results:  
Getter/setter defined in step 1 will be evaluated in the context of a new page.

Expected Results:  
Getter/setter defined in step 1 must be cleared when loading a new page.
Or, do not allow web pages to poison window.__proto__.__proto__.__proto__.
Comment 1 shutdown 2005-04-09 00:56:58 PDT
Created attachment 180152 [details]
testcase

testcase for the bug.
Comment 2 Daniel Veditz [:dveditz] 2005-04-09 11:08:45 PDT
Confirming.

If you set browser.dom.global_scope_pollution.disabled to true (undoing the IE
compat fixes in bug 256932) you can still do this, but using only two __proto__
instead of three.
Comment 3 Brendan Eich [:brendan] 2005-04-09 11:17:54 PDT
That is the last object on the prototype chain, namely Object.prototype.  We
should be resetting that to a new one created for a new Object ctor on new doc
load, of course.

/be
Comment 4 Johnny Stenback (:jst, jst@mozilla.com) 2005-04-09 14:38:17 PDT
Created attachment 180219 [details] [diff] [review]
Make context re-initialization work right again.

Not sure when or how this broke, didn't have time to dig into that yet. But the
problem is that XPConnect is unable to find Object.prototype when we're
re-initializing a context (i.e. during page transition), so it ends up using
the old one it had. That's bad, and there was code that printed out a warning
for that, but I hadn't been observant enough to notice that. I turned on that
code for everyone now to hopefully catch this earlier if it happens again.

So this patch makes it so that we can resolve standard classes during context
re-initialization. Pretty straight forward.
Comment 5 Chase Phillips 2005-04-09 14:40:30 PDT
Comment on attachment 180219 [details] [diff] [review]
Make context re-initialization work right again.

a=chase/drivers pending r/sr
Comment 6 Boris Zbarsky [:bz] (Out June 25-July 6) 2005-04-09 15:00:15 PDT
Comment on attachment 180219 [details] [diff] [review]
Make context re-initialization work right again.

r=bzbarsky.
Comment 7 Brendan Eich [:brendan] 2005-04-09 15:19:51 PDT
Comment on attachment 180219 [details] [diff] [review]
Make context re-initialization work right again.

I think that NS_WARNING should be an NS_ERROR.	Is that going to turn tinderbox
orange?  If so, we still have a potential security hole.

/be
Comment 8 Daniel Veditz [:dveditz] 2005-04-09 15:35:42 PDT
r=dveditz too, but get rid of the NS_WARNING and uncomment the NS_ERROR
Comment 9 Daniel Veditz [:dveditz] 2005-04-09 18:36:18 PDT
jst checked in to the aviary branch
Comment 10 Johnny Stenback (:jst, jst@mozilla.com) 2005-04-10 11:02:53 PDT
Fixed on the 1.7 branch too.
Comment 11 Mike Connor [:mconnor] 2005-04-21 11:35:47 PDT
Created attachment 181440 [details] [diff] [review]
trunk version of what got checked in
Comment 12 Mike Connor [:mconnor] 2005-04-21 14:05:39 PDT
landed on trunk
Comment 13 Boris Zbarsky [:bz] (Out June 25-July 6) 2005-05-26 08:50:22 PDT
This caused some pretty weird (though possibly correct) code flow during context
init.  I filed bug 295606 on that.
Comment 14 timeless 2005-06-08 09:44:17 PDT
Comment on attachment 181440 [details] [diff] [review]
trunk version of what got checked in

this patch was applied in cenzic hailstorm 2.6 against mozilla/ -mozilla1.8a5
and js/ -mozilla1.8b1

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