江苏龙网

  1. 首页 > 生活 > >

怎样看待最近爆出的 IE 全版本执行漏洞（CVE-2014-6332）( 二 )


Array Elements:
| Variant Type (WORD) | Padding (WORD) | Data High (DWORD) | Data Low (DWORD) |
Cutting to the chase, VBScript permits in-place resizing of arrays through the command “redim preserve.” This is where the vulnerability is.
redim preserve arrayname( newsizeinelements )
VBScript.dll contains a runtime evaluation method, CScriptRuntime::Run(VAR *), which farms out the SafeArray redimension task to OleAut32.dll with the SafeArrayRedim(…) function. Essentially, what happens is that fairly early on, SafeArrayRedim() will swap out the old array size (element count) with the resize request. However, there is a code path where, if an error occurs, the size is not reset before returning to the calling function, VBScript!CScriptRuntime::Run().
For VBScript, exploitation of this bug could have been avoided by invalidating the common “On Error Resume Next” VBScript code when the OleAut32 library returns with an error. Since it doesn’t, one can simply rely on this statement to regain script execution and continue to use “corrupted” objects. This VBScript code snippet is extremely common and its presence would not indicate that this vulnerability has been exploited.
Exploitation of VulnerabilityThis is the fun part. Although the bug originates in some very old code within the OleAut32 library, I’m approaching exploitation from the perspective of VBScript within Internet Explorer because all versions since 3.0 are vulnerable through this vector.
Exploitation is tricky, partially because array elements are a fixed size. Yet there are two additional issues that complicate exploitation. The first is that there is little opportunity to place arbitrary data where VBScript arrays are stored on the IE heap. The second issue is that, assuming you are now addressing outside the bounds of your VBScript array (Safe Array), you will find the unpleasant enforcement of Variant type compatibility matching.
【怎样看待最近爆出的 IE 全版本执行漏洞（CVE-2014-6332）】 In the end, the key to exploitation toward reliable code execution was to take advantage of the difference in the element alignment of the arrays (16 bytes) and the alignment of the Windows heap (8 bytes). This provides opportunities to change the Variant type in an element of an adjacent array and to read that content back through the original array reference.
In short, with this kind of memory manipulation available, an attacker can do a number of things. One possibility is to create arbitrary dispatch pointers for VT_DISPATCH or VT_UKNOWN types. This can lead to Data Execution Prevention (DEP) firing if the specified pointer does not correspond to a memory address with execution enabled. There are ways around that, too, but I’ll return to that later. Another possibility would be to use this attack to grab some heap data, but that is a little inconvenient because, again, you run into Variant type compatibility matching. If the location outside of the array boundary that would hold the Variant type is not a known Variant ID or combination on a read operation, or if it is not directly compatible on a write operation, nothing further will happen.


推荐阅读


上一篇：win10中文输入bug?不显示候选框，还会自动多出好多字母

下一篇：seo学习书籍帮忙给推荐些