Mimecast Discovers Use-After-Free Zero-Day Vulnerability in Adobe Reader  

Adobe Acrobat Reader is one of the most popular PDF readers, and as such, it remains a target for potential exploitation attempts. 

This article details how the Mimecast Threat Research Labs team and I began debugging a zero-day vulnerability encountered during an investigation into reproducing 1-day vulnerabilities in Adobe Acrobat Reader. 

Anatomy of PDF Annotations in Adobe Reader

Most modern document readers, including Adobe Acrobat Reader and Microsoft 365, implement features for annotations and comments.

In Adobe Acrobat Reader, the functionality for annotations is implemented in a DLL file named Annots.api.

During the course of our ongoing research, we decided to try to interact with the annotation feature using JavaScript for PDF. Luckily, Adobe documents the API for Acrobat’s Javascript engine (based on SpiderMonkey engine), highlighting that the following methods might be relevant:

Triggering a Crash

While testing annotations with an outdated version of Adobe, we tested a script designed to trigger a crash for an existing 1-day vulnerability, and while debugging it, an unexpected crash was introduced. The basic script had the logic below.

We created an annotation object:

var annot = this.addAnnot({})

Then added a text field to the annotation object:

var f = annot.addField("some_name", {"cFieldType":"text"}, something, something)

Finally, a trigger was set: the annotation object would be destroyed when the text field blurred.

f.setAction("OnBlur", "annot.destroy()")

When the annotation object was accessed programmatically, no unusual behavior was documented.

However, clicking the text field demonstrated that somehow Adobe Acrobat Reader could access the annotation object, therefore triggering a Use-After-Free bug and crashing the application.

We were seeing a classic Use-After-Free bug:

• Free: The annotation object is being freed on an OnBlur event on the text field.

f.setAction(“OnBlur”, “annot.destroy()”)

• Use: Clicking the annotation after clicking the text field triggered the OnBlur event and freed the UI object of the annotation, but at the same time, the UI object of the Annotation was being accessed by clicking it.

Technical Analysis

To verify the root cause of the crash (Use-After-Free), we debugged Acrobat Reader with WinDBG, and activated GFlags to troubleshoot the bug. To ease the task of debugging, we were forced to disable Protected Mode in Adobe Acrobat Reader.

When debugging the POC file to trigger the vulnerability, there was an access violation exception, as expected, due to access given to previously freed memory.

With a simple heap spray in our Javascript code, we also managed to gain control over EIP by corrupting a function pointer in one of Acrobat Reader’s internal objects, as seen in Figure 1:

Figure 1: Debugging and exception details in WinDBG

In our Javascript code, we sprayed the heap with 0x0c0d bytes, and it modified the value of the ESI register.

In addition, the EIP register pointed to the address 0x0, and we could see that the root cause of it was because of a call to a function located at ESI+0x20.

The value at the address ESI+0x20 was 0x0, which meant that the instruction pointer would be set to this value, and because we had control over ESI, we could also control the function address to be called.

Gaining control over EIP was not enough for successful exploitation, as in such scenarios the team needed to bypass additional mitigations such as ASLR, DEP, and Acrobat Reader’s sandbox.

Diving Deeper

When analyzing and potentially exploiting heap vulnerabilities, it’s important to understand the internals of the heap, and how the objects that we can corrupt are structured.

Understanding the internal objects of Acrobat Reader isn’t that easy, as the program has no published symbols (unlike Microsoft Office), and it requires additional reverse engineering.

After initial analysis of the vulnerability and the root cause of the vulnerability, the we decided to dive deeper.

For this task, we looked at two modules we thought were the most relevant for this vulnerability: Annots.api and AcroRd32.dll.

To make the analysis easier, we used WinDBG Preview and ran our POC file with Gflags and Time Travel Debugging enabled.

This way, we could capture a trace file of the execution and replay it backwards and forwards with the debugger.

We set a breakpoint at the first access we saw to the corrupted object, and when we reached the breakpoint, we wanted to see details on the corrupted heap chunk.

The screenshot below shows how we could see that the call to the function at 0x710e7b70 changed the contents of the buffer pointed by EDI, and demonstrates how we saw that this was our corrupted buffer.

Examining the heap chunk that pointed by EDI+0x7A, we could see that the chunk entry was at 0xb7c8010.

Now we wanted to set a hardware breakpoint on this address, rewind the execution (using Time Travel Debugging), and check all the accesses to this address, including freeing and allocating memory in this address.

Figure 2: First access to the corrupted object by our POC.

After we rewound the execution and debugged the trace file with the breakpoints we set, we examined all the accesses to the address of the corrupted heap chunk entry.

We wanted to have better understanding of the free heap chunk that was being used, which object it represented, the size of the object, and (preferably) its properties.

After we examined the accesses to the freed heap chunk and filtered the ones that related to memory allocations/free, we could see the user’s allocation size of the chunk in the call to RtlAllocateHeap with the argument of 0x2D0 as the size.

Figure 3: Object allocation with user size of 0x2D0 

So, at this point, we knew that the program allocated 0x2D0 bytes for the corrupted object, if we ignored the additional 0x18 bytes allocated by the heap manager.

As a reminder, the object was allocated by using the following Javascript code:

var annot = this.addAnnot({})

As we now had the call stack of the allocation, we were able to see where the object was being constructed by Acrobat Reader.

When we took a look at the code at address AcroRd32!AIDE::PixelPartInfo::operator=+0x4e697f, we could see the allocated buffer and the buffer size, and we also could see a call to a function (create_CommentContainerView_object_internal) that constructed the object itself with initial values. 

Figure 4: Construction of the object in AcroRd32!AIDE::PixelPartInfo::operator=+0x4e697f 

Once we knew how the object was being constructed, we could see that we freed it with the action that we set in the OnBlur event using the following Javascript code:

f.setAction("OnBlur", "annot.destroy()")

By checking the call stack during the free operation of the object, we could also see that it was being freed by calling the destroy() API in the Annots.api library: 

Figure 5: Call stack when freeing the object with the destroy() API 

In the call stack, we could see the execution of code in the address Annots!PlugInMain+0xabadf was called from the EScript module (Acrobat Reader Javascript engine).

Just by looking at the “destroy" string in the function, we discovered that the chunk had been freed by calling the destroy() API.

Figure 6: Code at Annots!PlugInMain+0xabadf 

Now that we knew that the object had been freed, we could see that we managed to take control over the free object by using generic Javascript functions for memory allocations (like creation of ArrayBuffer and DataView objects): 

Figure 7: Corruption of the free object by heap spraying with Javascript 

We could also see that the call stack in this scenario was different from the call stack that we saw in the this.addAnnot API call, and in this call stack, the allocation came from the EScript module of Acrobat Reader (the Javascript engine), and not from the Annots module as before.

To gain code execution using the vulnerability, we only needed to bypass security mitigations such as DEP, ASLR, Acrobat Sandbox and more.

Bypassing these mitigations required, in most cases, finding more vulnerabilities and chaining them together.

Disclosure Timeline for CVE-2022-38437

The vulnerability has been disclosed to Adobe through the HackerOne service.

• August 24 – The vulnerability was disclosed to Adobe through the HackerOne service
• August 25 – HackerOne analysts successfully reproduced the vulnerability and forwarded it to Adobe
• October 14 – Adobe patched the vulnerability and assigned it CVE-2022-38437

The Bottom Line

In this research, our goal was to reproduce 1-day vulnerabilities in Acrobat Reader in order to understand it better and find potential fuzzing targets, but eventually we ended up finding a zero-day vulnerability that we probably couldn’t reach with fuzzing, as it requires specific user interaction with Acrobat Reader’s GUI with combination of Javascript. This vulnerability could further aid attackers in gaining control of affected systems. It is our hope that discovering and sharing our research on this vulnerability will help prevent that from happening.