Last Comment Bug 313375 - DOM object can be used to circumvent security checks
: DOM object can be used to circumvent security checks
Status: RESOLVED FIXED
[sg:critical]
: fixed1.7.13, fixed1.8
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: x86 Windows 98
: P2 normal (vote)
: mozilla1.8rc1
Assigned To: Blake Kaplan (:mrbkap) (please use needinfo!)
: Hixie (not reading bugmail)
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-22 05:20 PDT by shutdown
Modified: 2007-04-01 15:28 PDT (History)
6 users (show)
dveditz: blocking1.7.13+
dveditz: blocking‑aviary1.0.8+
mscott: blocking1.8rc2+
bob: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (1.07 KB, text/html)
2005-10-22 05:20 PDT, shutdown
no flags Details
Fix (1.42 KB, patch)
2005-10-28 15:34 PDT, Blake Kaplan (:mrbkap) (please use needinfo!)
mrbkap: review+
mrbkap: superreview+
dveditz: approval‑aviary1.0.8+
dveditz: approval1.7.13+
asa: approval1.8rc2+
Details | Diff | Review

Description shutdown 2005-10-22 05:20:08 PDT
DOM object wrapper can be used to circumvent
security check for the "constructor" property.
Comment 1 shutdown 2005-10-22 05:20:54 PDT
Created attachment 200436 [details]
testcase

Works on:
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051021 Firefox/1.6a1
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b5) Gecko/20051021 Firefox/1.5
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.12) Gecko/20051021 Firefox/1.0.7
Comment 2 Daniel Veditz [:dveditz] 2005-10-24 09:37:20 PDT
Confirming because this works in 1.5b2 and 1.0.x, but it appears to be fixed in today's build ("function Function must be called directly, and not by way of a function of another name"). Is this a dupe of one of the recent ones blake fixed?
Comment 3 Blake Kaplan (:mrbkap) (please use needinfo!) 2005-10-24 10:50:59 PDT
This was "fixed" by the "belt" part of bug 313236 (i.e., we no longer allow calls to privileged Function constructors from "weak" code). I'm not sure if we want to fix this further up the chain, though. Thoughts are welcome.
Comment 4 Johnny Stenback (:jst, jst@mozilla.com) 2005-10-28 14:01:42 PDT
Here's what's going on here. We null out HTMLBodyElement, set document.body's prototype to a function from a chrome XBL binding. Then access document.body.constructor. That will resolve the property on the body, and since HTMLBodyElement has been set to null that fails to resolve (which is arguably a bug too, but not this bug), so we keep looking up the proto chain. We find the function, and it's got a constructor property. The JS engine then goes to get that, and sees that it's got a getter, calls the getter and that getter does a checkAccess call in the JS engine. Since this property is being  accessed off of document.body, we call document.body's JSClass' checkAcces hook. That checkAccess hook only protects against accessing certain properties (proto and parent, and watchpoints), and this is just a normal get of a vanilla property, so the hook just returns w/o doing a security check.

Now this could trivially be fixed in the DOM's checkAccess hook, but IMO that's wrong, and probably wouldn't catch all cases of this bug. Seems like if the Function JSClass cares about protecting access to its constructor property (as do all vanilla JS objects), the JS engine needs to call that class' checkAccess hook when a property on an instance of that class is accessed, even if indirectly if the instance is on some other object's prototype chain.

Thoughts?
Comment 5 Blake Kaplan (:mrbkap) (please use needinfo!) 2005-10-28 15:34:40 PDT
Created attachment 201202 [details] [diff] [review]
Fix

This has r=brendan. We need to call the checkAccess hook of the object that we found, not of the object that we're looking on, since if we ended up delegating the resolution, the original object might not care about the access, but the object that we ended up finding the property on might care.
Comment 6 Blake Kaplan (:mrbkap) (please use needinfo!) 2005-10-28 15:41:27 PDT
Comment on attachment 201202 [details] [diff] [review]
Fix

jst sez, "sr=jst".
Comment 7 Blake Kaplan (:mrbkap) (please use needinfo!) 2005-10-28 15:52:28 PDT
Checked into trunk. Tracking to hit rc2 in such an event.
Comment 8 Asa Dotzler [:asa] 2005-10-31 14:42:26 PST
Blake, have we fixed enough of this already with the other bug so that the security implications are remedied?
moving out to the 1.8 rc2 ride-along candidate list. We'll consider taking this if we do an RC2.
Comment 9 Blake Kaplan (:mrbkap) (please use needinfo!) 2005-10-31 16:39:17 PST
Fix checked into MOZILLA_1_8_BRANCH.
Comment 10 Daniel Veditz [:dveditz] 2006-02-02 15:28:49 PST
Comment on attachment 201202 [details] [diff] [review]
Fix

a=dveditz for drivers, please add fixed-aviary1.0.8 and fixed1.7.13 keywords when checked in.
Comment 11 timeless 2006-02-03 08:49:08 PST
Comment on attachment 201202 [details] [diff] [review]
Fix

mozilla/js/src/jsobj.c 	3.155.2.20 	MOZILLA_1_7_BRANCH
mozilla/js/src/jsobj.c 	3.155.2.1.4.6.2.12 	AVIARY_1_0_1_20050124_BRANCH
Comment 12 Jay Patel [:jay] 2006-02-13 12:50:10 PST
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/20060213 Firefox/1.0.8, permission denied in testcase.

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