Javascriptcore gettersetter type confusion during dfg compilation Vulnerability / Exploit
/
/
/
Exploits / Vulnerability Discovered : 2019-10-30 |
Type : dos |
Platform : multiple
This exploit / vulnerability Javascriptcore gettersetter type confusion during dfg compilation is for educational purposes only and if it is used you will do on your own risk!
[+] Code ...
The following JavaScript program, found by Fuzzilli and slightly modified, crashes JavaScriptCore built from HEAD and the current stable release (/System/Library/Frameworks/JavaScriptCore.framework/Resources/jsc):
The assertion indicates that a JSCell is incorrectly downcasted to a GetterSetter [1] (a pseudo object used to implement property getters/setter). In non debug builds, a type confusion then follows.
Below is my preliminary analysis of the cause of the bug.
The function v2 is eventually JIT compiled by the FTL JIT compiler. Initially, it will create the following (pseudo) DFG IR for it:
# Block 0 (before if-else):
44: NewObject(...)
<jump to block 1 or 2 depending on v5>
# Block 1 (the if part):
... <install .length property on @44>
// Code for const v15 = (140899729)[140899729];
ForceOSRExit
Unreachable
# Block 2 (the else part)
PutByOffset @44, notAGetterSetter
PutStructure
# Block 3 (after the if-else):
...
// Code for v10.length. Due to feedback from previous executions, DFG
// JIT speculates that the if branch will be taken and that it will see
// v10 with a GetterSetter for .length here
CheckStructure @44, structureWithLengthBeingAGetterSetter
166: GetGetterSetterByOffset @44, .length // Load the GetterSetter object from @44
167: GetGetter @166 // Load the getter function from the GetterSetter
...
Here, the end of block 1 has already been marked as unreachable due to the element load from a number which will always cause a bailout.
Later, the global subexpression elimination phase [2] runs and does the following (which can be seen by enabling verbose CSE [3]):
* It determines that the GetGetterSetterByOffset node loads the named property from the object @44
* It determines that this property slot is assigned in block 2 (the else block) and that this block strictly dominates the current block (meaning that the current block can only be reached through block 2)
* This is now the case as block 1 does a bailout, so block 3 can never be reached from block 1
* As such, CSE replaces the GetGetterSetterByOffset operation with the constant for |notAGetterSetter| (as that is what is assigned in block 2).
At this point the IR is incorrect as the input to a GetGetter operation is expected to be a GetterSetter object, but in this case it is not. During later optimizations, e.g. the AbstractInterpreter relies on that invariant and casts the input to a GetterSetter object [4]. At that point JSC crashes in debug builds with the above assertion. It might also be possible to trigger the type confusion at runtime instead of at compile time but I have not attempted that.