SSD Advisory – Acrobat Reader DC – Stream Object Remote Code Execution

Credit to Author: SSD / Maor Schwartz| Date: Wed, 09 Aug 2017 10:50:38 +0000

Want to get paid for a vulnerability similar to this one?
Contact us at: sxsxdx@xbxexyxoxnxdxsxexcxuxrxixtxy.xcom

Vulnerability Summary
The following advisory describes a use after free vulnerability that leads to remote code execution found in Acrobat Reader DC version 2017.009.20044.

Credit
A security researcher from, Siberas, has reported this vulnerability to Beyond Security’s SecuriTeam Secure Disclosure program

Vendor response
The vendor has released patches to address this vulnerability.
For more information: http://www.adobe.com/devnet-docs/acrobatetk/tools/ReleaseNotes/DC/dccontinuousaug2017.html#dccontinuousaugusttwentyseventeen

CVE: CVE-2017-11254

Vulnerability details
Adobe Reader DC, are affected by a Use After Free vulnerability. The vulnerability occurs due to a Stream object being dereferenced after it has been destroyed. The re-use of the freed object directly leads to a controllable vtable call. By controlling the vtable we can execute arbitrary code in the sandboxed AcroRd32.exe process.

The vtable pointer is read from offset 0x18 of the freed object:

The Javascript code which triggers the vulnerable code path is:

At [1] we create two objects with defined getter-methods for the “read” and “write” properties. These two objects are passed as parameters to the native function “this.addAnnot” at [2].

During addAnnot the objects are checked for the “read” and “write” properties. If we return a valid function (in this case “somefunc”) for the “write” properties and “undefined” for the “read” properties, we trigger a Use-After-Free vulnerability.

Acrobat Reader DC initializes a temporary Stream object because the “write” property returns a valid function and destroys it immediately afterwards since “read” returns undefined. Due to the fact that a reference to the destroyed Stream object stays intact, we can reference the Stream object again after it has been freed.

There are further callbacks between the destruction and the re-use of the object which gives us the chance to re-allocate the freed buffer with controlled content (at [3]) and execute a controlled vtable call as soon as the Stream object is dereferenced again.

In order to debug the vulnerability, we will set the following breakpoints in Reader:

Debugging poc.pdf with Windbg and the breakpoints from above will give you following output:

In the debug log we can identify the allocation [1], destruction [2] and re-use [3] of the Stream object and the controlled vtable call at address 0xdead0cde.

Proof of Concept

PoC.pdf

PoC.js

Print Friendly, PDF & Email

https://blogs.securiteam.com/index.php/feed