By Elliot Cao (Vulnerability Researcher)
Last June, I disclosed a use-after-free (UAF) vulnerability in Internet Explorer (IE) to Microsoft. It was rated as critical, designated as CVE-2019-1208, and then addressed in Microsoft’s September Patch Tuesday. I discovered this flaw through BinDiff (a binary code analysis tool) and wrote a proof of concept (PoC) showing how it can be fully and consistently exploited in Windows 10 RS5.
A more in-depth analysis of this vulnerability is in this technical brief. Here’s an overview of the research.
As mentioned, CVE-2019-1208 is a UAF vulnerability. This class of security flaws can corrupt valid data, crash a process, and, depending on when it is triggered, can enable an attacker to execute arbitrary or remote code. In the case of CVE-2019-1208, an attacker successfully exploiting this vulnerability could gain the same rights as the current user in the system. If the current user has administrative privileges, the attacker can hijack the affected system — from installing or uninstalling programs and viewing and modifying data to creating user accounts with full privileges.
A more tangible attack scenario would entail attackers sending socially engineered phishing emails to unknowing users and tricking them into accessing a malicious website (containing an exploit for CVE-2019-1208) via Internet Explorer. Alternatively, an attacker can send spam emails with attachments containing an exploit for the vulnerability. These attachments can be a Microsoft Office document that has the IE rendering engine enabled, or application files embedded with an ActiveX control that, in turn, contains an exploit for the vulnerability. Attackers could also compromise and host an exploit on legitimate websites, like those that accept content or input (i.e., advertisements) from users.
Figure 1. Code flow of VbsJoin
My research started with BinDiff, when I was trying to compare the changes made on the functions in vbscript.dll, a module that contains the API functions for the VBScript engine, between May and June. I saw that there were fixes made via the SafeArrayAddRef, SafeArrayReleaseData, and SafeArrayReleaseDescriptor functions.
Probing further, however, and inspired by a vulnerability (CVE-2018-8373) I previously uncovered, I used VBScriptClass and was able to trigger a UAF issue through these steps:
Figure 2. Snapshots of code showing arr = Array(New MyClass) in memory (top), arr = Array(0) in memory, and the callback (highlighted, bottom)
When saving the VbsJoin return value to arr(0), the PoC crashes in vbscript!AccessArray (Figure 3) because the SafeArrayDescriptor is freed and the Variant arr still saves the pointer of the freed SafeArrayDescriptor.
Figure 3. Snapshot of code showing how the PoC crashed in vbscript!AccessArray
In a way, yes, but to a limited extent. To demonstrate how UAF can be fully triggered, I used basic string/binary string (BSTR) as the data structure. SafeArray is a multidimensional array, but since VbsJoin can only process a one-dimensional array, I changed the SafeArray dimensions in the callback. Unfortunately, it still didn’t work. It throws a runtime error that says the array type does not match in Join. I used On Error Resume Next to bypass this runtime error. Figure 4 is the modified PoC.
Figure 4. Modified PoC that used On Error Resume Next
After getting 0x20 bytes of freed memory, I used BSTR whose size is 0x20 bytes to fake a big-size SafeArray. By using heap feng shui, this BSTR can reuse the 0x20 bytes freed memory stably. As shown in Figure 5 (top), I finally got a fake, one-dimensional SafeArray whose element number is 0x7ffffffff and element size is 1 byte:
Figure 5. Faked SafeArray (top) and fixed address for read/write (bottom)
I was able to make a fake SafeArray that can be used to read/write memory from 0x00000000 to 0x7fffffff. To leak some read/write address for exploitation, I applied Simon Zuckerbraun’s previous research and used heap spray to give me some fixed read/write address (0x28281000), as seen in Figure 4 (bottom).
I used the Scripting.Dictionary object to perform remote code execution (RCE) as explained in Simon Zuckerbraun’s blog, but used another method to make a fake Dictionary. This time, I used BSTR and carried these out, as shown in Figure 6:
Figure 6. Faked Dictionary memory layout
On August 13, 2019, VBScript, which has already been disabled in Windows 10, was disabled for Internet Explorer 11 in Windows 7, 8, and 8.1. Therefore, the PoC detailed here was developed in local mode. But as Microsoft says, this setting can still be enabled via Registry or Group Policy. All the same, users and organizations should always adopt best practices: Keep systems patched and updated, disable components if they are not needed (or restrict use), and foster cybersecurity awareness on vectors that may be used by attackers, such as spam emails and other socially engineered threats.
The complete details of the research are in this technical brief.
The post From BinDiff to Zero-Day: A Proof of Concept Exploiting CVE-2019-1208 in Internet Explorer appeared first on .
The head of counterintelligence for a division of the Russian Federal Security Service (FSB) was… Read More
For nearly a dozen years, residents of South Carolina have been kept in the dark… Read More
The U.S. government is warning that “smart locks” securing entry to an estimated 50,000 dwellings… Read More
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) said today it is investigating a breach… Read More
On April 9, Twitter/X began automatically modifying links that mention “twitter.com” to read “x.com” instead.… Read More
If only Patch Tuesdays came around infrequently — like total solar eclipse rare — instead… Read More