SSD Advisory – Adobe Reader DC – execMenuItem Off-by-One Heap Buffer Overflow

Credit to Author: SSD / Maor Schwartz| Date: Wed, 09 Aug 2017 10:47:48 +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 JavaScript execMenuItem off-by-One heap buffer overflow, that can potentially lead to Remote Code Execution, found in Adobe Reader DC version 15.23.20056.213124.

Credit
An independent security researcher, Steven Seeley, 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-11220

Vulnerability Details
An attacker can craft a specially designed PDF that forces an off-by-one heap buffer overflow in the script engine. This can potentially allow an attacker to leak information or gain remote code execution.

If we will look at the debugger output, we will see the following:

Then, we will display the global flags

And the use the !avrf command:

Now we know the heap chunk is size 0x1d that is overflowed. So for exploitation, we need to make sure our target chunk is 0x1d in size.

Lets get the chunk header

Now, lets inspect the heap chunk with the complete header

We can also get the chunks stack trace form the StackTrace pointer in the heap header:

Now that we know where the allocation is, we can set a break-point just past it and dump its information before the overflow occurs.

First, we will get the module name, since it changes due to ASLR:

Now, we set the breakpoints. The second break-point is set into the operator new and will trigger to enable the first break-point which is just after the allocation.

Then the first break-point will set a hardware break-point on the newly allocated chunk just past the size of the chunk to catch the off-by-one, and then continue execution.

Second re-run of the vulnerability

Then we will run the following command:

We can see that the written byte is here

Just to confirm we are looking at the right chunk:

Now we will find exactly where the overwrite occurs by looking at the wcstombs call:

Now, we will get the offset for IDA using IDA’s base for AcroRd32.dll

Third re-run of the vulnerability:

If we re-run it again and set a breakpoint right at that location where the wcstombs is called, we see the following:

Destination target buffer for the overflow:

Source buffer:

Static Analysis:

We know that the vulnerability is caused from a call to wcstombs inside sub_60824C1E:

The target buffer size is 0x1d and the string is 0x1e in length, leading to an off-by-one overflow in the heap:

Proof of Concept

Print Friendly, PDF & Email

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