Even though it can be (and actually is, in the PoC) incremented in an overloaded TerminateClass function, no checks will be made before finally freeing the class object.\n\n() is a deprecated method, now replaced by the 'Finalize' procedure. Inside the VBScriptClass::Release function, the reference count is checked only once, at the beginning of the function. In this case, VBScriptClass::Release is called to destroy the object correctly and handle destructors like Class_Terminate, since the VARTYPE of ArrA(1) is VT_DISPATCH.\n\n()]()\n\n_Root cause of CVE-2018-8174 - 'refCount' being checked only once, before TerminateClass function_\n\nThis ends up being the root cause of the vulnerability. This is possible because when \"Erase ArrA\" is called, the vbscript!VbsErase function determines that the type of the object to delete is a SafeArray, and then calls OLEAUT32!SafeArrayDestroy.\n\nIt checks that the pointer to a () is not NULL and that its reference count, stored in the cLocks field is zero, and then continues to call ReleaseResources.\n\n()]()\n\n_VARTYPE of ArrA(1) is VT_DISPATCH, so VBScriptClass::Release is called to destruct the object_\n\nReleaseResources, in turn will check the fFeatures flags variable, and since we have an array of VARIANTs, it will subsequently call VariantClear a function that iterates each member of an array and performs the necessary deinitialization and calls the relevant class destructor if necessary.
To trigger the vulnerability this code could be minimized to the following proof-of-concept (PoC):\n\n()]()\n\n_CVE-2018-8174 Proof Of Concept_\n\nWhen we then launch this PoC in Internet Explorer with page heap enabled we can observe a crash at the OLEAUT32!VariantClear function.\n\n()]()\n\n_Access Violation on a call to freed memory_\n\n()]()\n\n_Freed memory pointer is reused when the second array (ArrB) is destroyed_\n\nWith this PoC we were able to trigger a Use-after-free vulnerability both ArrA(1) and ArrB(1) were referencing the same 'ClassVuln' object in memory. This technique allows one to load and render a web page using the IE engine, even if default browser on a victim's machine is set to something different.\n\nThe VBScript in the downloaded HTML page contains both function names and integer values that are obfuscated.\n\n()]()\n\n_Obfuscated IE exploit_\n\n# **Vulnerability root cause analysis**\n\nFor the root cause analysis we only need to look at the first function ('TriggerVuln') in the deobfuscated version which is called right after 'RandomizeValues' and 'CookieCheck'.\n\n()]()\n\n()]()\n\n_Vulnerability Trigger procedure after deobfuscation_\n\nTo achieve the desired heap layout and to guarantee that the freed class object memory will be reused with the 'ClassToReuse' object, the exploit allocates some class objects. This is the first time we've seen a URL Moniker used to load an IE exploit, and we believe this technique will be used heavily by malware authors in the future. Despite a Word document being the initial attack vector, the vulnerability is actually in VBScript, not in Microsoft Word. ) is not in the list, which is why the MSHTML COM server is successfully created in Word context.\n\nThis is where it becomes interesting.
0 kommentar(er)
