Last Comment Bug 86028 - can redefine focus() and other allAccess functions at another domain
: can redefine focus() and other allAccess functions at another domain
Status: RESOLVED FIXED
[sg:fix]
: csectype-sop, fixed1.4.3
Product: Core
Classification: Components
Component: Security: CAPS (show other bugs)
: Trunk
: x86 Windows NT
: P2 minor (vote)
: ---
Assigned To: Daniel Veditz [:dveditz]
: bsharma
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2001-06-14 21:23 PDT by Jesse Ruderman
Modified: 2013-06-09 18:47 PDT (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
demo using blur() (536 bytes, text/html)
2001-06-14 21:35 PDT, Jesse Ruderman
no flags Details
Only allow getting allAccess functions across domains, don't allow setting them. (3.90 KB, patch)
2004-03-24 14:56 PST, Johnny Stenback (:jst, jst@mozilla.com)
caillon: review+
dveditz: superreview+
caillon: approval1.4.3+
dveditz: approval1.7+
Details | Diff | Splinter Review

Description Jesse Ruderman 2001-06-14 21:23:07 PDT
I can redefine focus() and several other functions on pages at another domain.  
I should only be able to call these functions, not redefine them.  The 
redefined function runs with the principal of the attacker, and these functions 
aren't called with interesting parameters, so this isn't a huge security hole.

Here's the line form all.js:
  pref("capability.policy.default.Window.focus", "allAccess");

I think this should be
  pref("capability.policy.default.Window.focus.get", "allAccess");
but I couldn't figure out how to test that change.
Comment 1 Jesse Ruderman 2001-06-14 21:35:16 PDT
Created attachment 38551 [details]
demo using blur()
Comment 2 Mitchell Stoltz (not reading bugmail) 2001-07-26 16:25:41 PDT
Target is now 0.9.4, Priority P2.
Comment 3 Jesse Ruderman 2001-08-20 17:21:15 PDT
Similar to bug 77503, possible to set window.toString for another domain.
Comment 4 Mitchell Stoltz (not reading bugmail) 2001-09-04 16:54:18 PDT
Not critical for 0.9.4, moving to 0.9.5.
Comment 5 Mitchell Stoltz (not reading bugmail) 2001-09-21 17:12:24 PDT
This appears to be fixed now, but the behavior is a little surprising. When I
call x.focus(), where x is a window at another domain, XPConnect calls the
security manager regarding a call to Window.focus(). When I attempt to redefine
x.focus(), the DOM helper at nsDOMClassInfo calls the AddProperty security
check, and that's what gets rejected. 

I think this is the correct behavior. Jesse, can you verify that this bug is
fixed and maybe try some variations?
Comment 6 bsharma 2001-10-18 13:30:34 PDT
Verified on 2001-10-10-branch build on WinNT

I get the following error on the Js console when I run the attached test case

Error: uncaught exception: Permission denied to set property Window.scriptglobals
Comment 7 Mitchell Stoltz (not reading bugmail) 2002-11-11 17:40:23 PST
This bug appears to have re-emerged.
Comment 8 Daniel Veditz [:dveditz] 2004-03-24 13:23:58 PST
dang, fell through the cracks!
Comment 9 Johnny Stenback (:jst, jst@mozilla.com) 2004-03-24 14:48:07 PST
Seems like Jesse's suggestion works as expected, patch coming up.
Comment 10 Johnny Stenback (:jst, jst@mozilla.com) 2004-03-24 14:56:59 PST
Created attachment 144693 [details] [diff] [review]
Only allow getting allAccess functions across domains, don't allow setting them.
Comment 11 Christopher Aillon (sabbatical, not receiving bugmail) 2004-03-24 15:42:08 PST
Comment on attachment 144693 [details] [diff] [review]
Only allow getting allAccess functions across domains, don't allow setting them.

What is
http://lxr.mozilla.org/mozilla/source/calendar/sunbird/app/profile/all.js and
does that need the same changes?  r=caillon once you figure that out.
Comment 12 Johnny Stenback (:jst, jst@mozilla.com) 2004-03-24 16:33:09 PST
Hmm, messed up. Yeah, that should be updated as well, but I think I'd rather
file a bug on Sunbird to not duplicate all.js, since that's a mantenance
nightmare, something we really really don't want with files like this. There are
better ways. I filed bug 238569 on sunbird to not use a copy of all.js. But for
now, I don't think we need to worry about that.
Comment 13 Christopher Aillon (sabbatical, not receiving bugmail) 2004-03-24 17:05:19 PST
Fair enough.
Comment 14 Daniel Veditz [:dveditz] 2004-03-24 21:42:42 PST
What am I missing? If I apply the patch the "demo using blur()" testcase still
shows the bug for me.
Comment 15 Johnny Stenback (:jst, jst@mozilla.com) 2004-03-24 22:48:04 PST
Hmm, is your Mozilla build finding other prefs that override what you're
setting? Does about:config reflect what you've changed in your all.js pref file?
Comment 16 Johnny Stenback (:jst, jst@mozilla.com) 2004-03-24 23:26:57 PST
Hmm, I guess we don't show these prefs in about:config at all, so that's not
very helpful.

I double checked that this does indeed fix the problem for me, I tried in a
SeaMonkey debug tree, and in a Firefox release tree, problem solved in both
cases. I now get an exception when trying to set window.blur across domains
(using the attached testcase).
Comment 17 Johnny Stenback (:jst, jst@mozilla.com) 2004-03-24 23:31:12 PST
Those trees were both WinXP builds, tested on Linux (Firefox) as well.
Comment 18 Daniel Veditz [:dveditz] 2004-03-25 12:37:23 PST
Comment on attachment 144693 [details] [diff] [review]
Only allow getting allAccess functions across domains, don't allow setting them.

My bad -- misled by the all.js that's still installed under defaults\pref. The
active settings from from the [GRE]\greprefs dir. Works just fine

sr=dveditz
a=dveditz for 1.7
Comment 19 Johnny Stenback (:jst, jst@mozilla.com) 2004-03-25 14:27:50 PST
Fix checked in, closing bug.
Comment 20 Hiro 2004-03-25 18:14:59 PST
Hard coding of the following pref is carried out in Camino.
Isn't this influenced?
  capability.policy.default.Window.blur
  capability.policy.default.Window.close
  capability.policy.default.Window.focus
http://lxr.mozilla.org/mozilla/source/camino/src/preferences/PreferenceManager.mm#329
(It may still be in other places.)

Comment 21 Hiro 2004-03-25 18:49:05 PST
pinkerton-san,
Please check, "capability.policy.default.*"
Comment 22 Christopher Aillon (sabbatical, not receiving bugmail) 2004-03-25 18:57:36 PST
crot0@infoseek.jp, camino is not setting default prefs, but clearing user set
values.  Look at the code.  By doing so, it is setting everything to the default
which is in all.js.   If for whatever reason camino does not have this all.js,
then the default values would be "sameOrigin" and that is not succeptible to
this bug.
Comment 23 neil@parkwaycc.co.uk 2004-03-29 00:32:15 PST
(In reply to comment #16)
>Hmm, I guess we don't show these prefs in about:config at all, so that's not
>very helpful.
That behaviour predates my involvement with about:config so I just carried it
forward but perhaps you'd like a pref to show those prefs or something ;-)
Comment 24 Johnny Stenback (:jst, jst@mozilla.com) 2004-03-29 17:40:06 PST
(In reply to comment #23)
> (In reply to comment #16)
> >Hmm, I guess we don't show these prefs in about:config at all, so that's not
> >very helpful.
> That behaviour predates my involvement with about:config so I just carried it
> forward but perhaps you'd like a pref to show those prefs or something ;-)

I'm fine either way. I don't want people to mess with those pefs too much, so
there's some value in not showing them to the users of about:config...
Comment 25 Daniel Veditz [:dveditz] 2004-06-17 13:35:41 PDT
Adding Jon Granrose to CC list to help round up QA resources for verification
Comment 26 Christopher Aillon (sabbatical, not receiving bugmail) 2004-07-08 13:08:13 PDT
Comment on attachment 144693 [details] [diff] [review]
Only allow getting allAccess functions across domains, don't allow setting them.

a=blizzard

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