The Windows VBScript Engine RCE vulnerability of CVE-2018-8174 analysis and use-vulnerability and early warning-the black bar safety net

ID MYHACK58:62201891947
Type myhack58
Reporter 佚名
Modified 2018-11-08T00:00:00


A, vulnerability introduction The VBScript Engine handles objects in memory there is a remote code execution vulnerability. The vulnerability could an attacker can in the current context of the user in the execution of arbitrary code in the way to spoil the memory. Successful exploitation of this vulnerability an attacker can obtain the current user with the same user permissions. If the current user is used to manage user permissions to log on, the successful exploitation of this vulnerability an attacker can control an affected system. The attacker could then install programs; view, change, or delete data; or create full user permissions to the new account. In a Web-based attack scenario, an attacker can through Internet Explorer using the vulnerability of a particular site, and then convince a user to view the website. The attacker can also in carrying the IE rendering engine application program or Microsoft Office embedded in the document marked as“safe for initialization”ActiveX controls. The attacker can also take advantage of compromised websites and accept or host user-provided content or advertisements. These sites may contain potentially exploit this vulnerability specially crafted content. 2018 5 on 8 November, Microsoft released security patches, the impact of the popular most System version. Vulnerability basic information Vulnerability ID CVE-2018-8174 Vulnerability name Microsoft VBScript Engine remote code execution vulnerability Vulnerability type Remote code execution Threat type UAF The impact of the system version Windows 7 x86 and x64 versions, RT8. 1, the Server 2008 & R2/2012 & R2/2016, an 8.1, 10 and Server version

Second, vulnerability testing System environment Win7 32 IE IE8 EXP

Third, the vulnerability principle Since the sample confusion severe, the part of the code shown in Figure 1, where the use of a simplified POC analysis, the code shown in Figure 2.

! Figure 1 sample using a serious confusion

! Figure 2 Crash Poc Crash Poc defined in the two arrays array_a and array_b, and declares a class MyTest, and overload the destructor Class_Terminate, the UAF created in the MyTest instance is assigned to Array array_a (1), and by the Erase array_a empty the array_a elements in the destructor array_a elements of time will trigger the script in the Class_Terminate of the call, in the Class_Terminate adds a array_b(0)to the MyTest instance of the reference MyTest instance of the reference count of+1, and then by array_a (1)= 1 Delete array_a (1) to MyTest instance of the reference MyTest instance reference count-1 to balance the reference count, this time the MyTest instance will be released, but array_b(0)still retains the MyTest instance reference, so array_b(0)points to be released in the MyTest instance of memory, and ultimately in MyTestVuln by b(0) = 0 access not allocated memory to trigger the vulnerability. ! When we enable page heap of IE browser to run this PoC, we can observe OLEAUT32! VariantClear function the crash occurs: the call is released the memory when an access violation occurs Access Violation)abnormalities. ! From the heap of information can be seen in eax(0x14032fd0)in the vbscript! VbsErase the call stack is released, the vbscript! VbsErase that corresponds to the script in the Erase, and eax is what is VBScriptClass::Release function to release the VBScriptClass object that is in the script MyTest instance. VBScriptClass::Release logic the following figure: ! VBScriptClass::Release in the first VBScriptClass reference count-1(&VBScriptClass;+0×4 if the reference count=0 then call VBScriptClass::TerminateClass, call VBScriptClass::TerminateClass because in the script overloads the Class_Terminate function, so to get a script execution opportunity, there will be in the release VBScriptClass memory before the imminent release of the VBScriptClass memory address stored in the script is control variable(Set array_b(0) =array_a(1)), and by array_a (1) = 1 to balance the reference count, the final release of the memory. ! Set array_a(1) = New MyTest, VBScriptClass the reference count is 2. Erase array_a returns, MyTest points to memory that has been released, but array_b(0)still point to this block is released the memory, The formation of a dangling pointer, see below: !

Fourth, exploit analysis UAF exploits the key is how to use this dangling pointer to the operation memory. The vulnerability is the use of multiple UAF to complete type confusion, by forge precision array of objects to accomplish any address read and write, and ultimately through the construction of the object after release to get the code executed, code execution does not use a conventional ROP technology or GodMod technology, but through the script layout Shellcode use. 1) falsification of an array to achieve any writing purpose By UAF manufacturing 2 class mem members point to the offset difference between the 0x0c byte, by 2 objects mem members of the read-write operation forged a 0x7fffffff size of the array. Forgery of the array is substantially the situation is: a one-dimensional array, the elements are 7fffffff, each element occupies 1 byte, the element memory address to 0. So the array can be accessed in the memory space 0x00000000 to 0x7ffffffff*1 in. Therefore, by the array can be any address read and write. But in lIlIIl in the storage when the storage type is a string type, so only need the data type will be modified to 0x200C, i.e. VT_VARIANT|VT_ARRAY array type, you can achieve the purpose. 2) reads the specified parameter of the memory data !

[1] [2] next