__defineGetter__ and __defineSetter__ can mutate non-configurable properties

RESOLVED FIXED

Status

()

Core
JavaScript Engine
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: Waldo, Unassigned)

Tracking

unspecified
Points:
---

Firefox Tracking Flags

(firefox12 verified)

Details

(Whiteboard: fixed by bug 715821 [qa+])

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.
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.
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.
According to comment 1 this should be fixed
Status: NEW → RESOLVED
Last Resolved: 6 years ago
status-firefox12: --- → fixed
Resolution: --- → FIXED
Whiteboard: fixed by bug 715821
Whiteboard: fixed by bug 715821 → fixed by bug 715821 [qa+]
CC'ing moz_bug_r_a4 to see if this leads to any interesting vulnerabilities
Waldo: what's your best guess about a security severity here, and should we take this on the ESR branch?
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.
Group: core-security
Verified with Firefox 12.0b6 js-shell with the input from comment 0.
Got: typein:3: TypeError: can't redefine non-configurable property 'x'
status-firefox12: fixed → verified
You need to log in before you can comment on or make changes to this bug.