Last Comment Bug 715819 - __defineGetter__ and __defineSetter__ can mutate non-configurable properties
: __defineGetter__ and __defineSetter__ can mutate non-configurable properties
Status: RESOLVED FIXED
fixed by bug 715821 [qa+]
:
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: unspecified
: All All
: -- normal (vote)
: ---
Assigned To: general
:
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-05 22:44 PST by Jeff Walden [:Waldo] (remove +bmo to email)
Modified: 2012-04-19 08:11 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
verified


Attachments

Description Jeff Walden [:Waldo] (remove +bmo to email) 2012-01-05 22:44:40 PST
Good behavior:

[jwalden@wheres-wally firefox]$ ~/moz/slots/js/src/gcc-dbg/js
js> var obj = { get x() { return 17; } };
js> Object.defineProperty(obj, "x", { configurable: false });
({get x () {return 17;}})
js> Object.defineProperty(obj, "x", { set: function(v) { print(v); } })
typein:3: TypeError: can't redefine non-configurable property 'x'

Bad behavior:

[jwalden@wheres-wally firefox]$ ~/moz/slots/js/src/gcc-dbg/js
js> var obj = { get x() { return 17; } };
js> Object.defineProperty(obj, "x", { configurable: false });
({get x () {return 17;}})
js> obj.__defineSetter__("x", function(v) { print(v); });
js> obj
({get x () {return 17;}, set x (v) {print(v);}})

I wonder what the chances are that we rely on a non-configurable accessor property never mutating, or its shape remaining live and in use, or *something* of that nature, such that this can be turned into something exploitable.  Non-negligible, I bet.  But I don't much know what reliances our JITs or anything are making these days.  bhackett?  dvander?  bueller?

I've already written a patch to fix this which I'll be posting in another bug (not filed yet).  I discovered this issue when analyzing the patch for potential behavioral differences from the current code.  I plan to file that bug, and post that patch, while doing what I can to not clue anyone watching to the existence of this flaw in the existing code.
Comment 1 Jeff Walden [:Waldo] (remove +bmo to email) 2012-01-05 22:55:52 PST
The patch is in bug 715821.  I'm not going to mark a dependence or relationship for the moment out of an abundance of caution/paranoia.
Comment 2 Brian Hackett (:bhackett) 2012-01-06 05:03:09 PST
Nothing I know of performs optimizations based on a property being non-configurable.  We can assume that a property will remain a data property, but as soon as __defineGetter__, delete or any other reconfiguration happens it will be marked as such and the code deoptimized.
Comment 3 Daniel Veditz [:dveditz] 2012-01-11 17:02:39 PST
According to comment 1 this should be fixed
Comment 4 Daniel Veditz [:dveditz] 2012-03-29 16:51:07 PDT
CC'ing moz_bug_r_a4 to see if this leads to any interesting vulnerabilities
Comment 5 Daniel Veditz [:dveditz] 2012-04-05 16:26:59 PDT
Waldo: what's your best guess about a security severity here, and should we take this on the ESR branch?
Comment 6 Jeff Walden [:Waldo] (remove +bmo to email) 2012-04-05 16:30:54 PDT
Given comment 2, and that every time I assume we've optimized for some ECMAScript invariant only to find out that we haven't yet, I don't think we need to worry about this -- unhiding.
Comment 7 Virgil Dicu [:virgil] [QA] 2012-04-19 08:11:25 PDT
Verified with Firefox 12.0b6 js-shell with the input from comment 0.
Got: typein:3: TypeError: can't redefine non-configurable property 'x'

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