Dissecting CVE-2018-4990, an Adobe Reader Vulnerability
For years, one of the most popular vectors for malware and attackers has been the humble PDF. There are a number of reasons for this, including the relative sophistication of the format and the capabilities it has for scripting as well as its cross-platform ubiquity. Indeed, Google shows over 4 billion PDFs indexed with countless more unindexed on the dark web.
Recently security researchers at ESET wrote A Tale of Two Zero Days, documenting a malicious PDF that exploits a remote-code execution vulnerability (CVE-2018-4990) in Adobe Reader and a privilege escalation vulnerability (CVE-2018-8120) in Microsoft Windows. The Keysight ATI team captured the PDF sample (MD5: bd23ad33accef14684d42c32769092a0) and analyzed the Adobe Reader vulnerability. This vulnerability is deployed in our last ATI release.
Windows 7 x86 SP1
Adobe Acrobat Reader DC 18.09.20044
JP2Klib.dll version 1.2.39492
First of all, we need to locate where the vulnerability is triggered. We enable the page heap in Adobe reader, attach windbg and open the PDF sample. To enable page heap, use this command:
gflags /i Acrobat.exe +ust +hpa
This is done so that when there is a heap overflow we can capture the exception.
Figure 1: using gflags to capture an access violation by CVE2018-4990
Acrobat Reader throws an access violation exception and we can observe that the EDX register has the value of 0xd0d0d0b0. Since the suffix fill pattern in the heap page is 0xd0d0d0d0, we can assume that this is the heap page that is freed by the vulnerable function. After checking the stack trace we can find a potential vulnerable function JP2KLib!JP2KCopyRect in the JP2KLib library as shown below.
Next, we locate the code block of the function JP2KCopyRect in JP2KLib.dll.
Converted to pseudocode, it looks like this:
Then we clean the code and figure out the logic to make it is easier to read:
It seems that this code block tries to loop from a base address and use the variable v114 as a counter to free memory. We can set breakpoints to check the values the malware is using for base, max and v114. The variable base is the memory address where it starts in this loop and v114 is the counter in the while loop.
bp JP2KLib+50588 //get value of max
bp JP2KLib+50567 // get value of base and value of v114
bp JP2KLib+5056e //get free function address
Next, we examine the base address after restarting windbg. The size of the memory allocated is 0x03f4 as is shown below in Figure 9.
Here we can clearly see that why the vulnerability is triggered. In Figure 7, max = 0xff, max*4 = 0x03fc, and the base address is 0x03f4. Since the while loop can access from the base address to base address + 0x3fc, as shown in Figure 5, Adobe Reader can read 8 bytes (0x3fc – 0x3f4) out of bounds and free that 8 bytes. These 8 bytes can be used as our memory layout for a heap spray attack. When JP2Klib requests memory when processing a JPEG2000 object embedded in the sample pdf file, the vulnerable function JP2KLib!JP2KCopyRect is called. The exploit can then use heap spraying to free arbitrary addresses (0x0d0e0048 and 0x0d0f0048 in the sample) before the vulnerability is triggered. When the vulnerability is triggered, the exploit is then able to use those addresses.
Leverage Our Subscription Service to Stay Ahead of Attacks
The bad guys never rest. There are always new vulnerabilities and exploits. One way of keeping up with the bad guys is with the Ixia BreakingPoint Application and Threat Intelligence (ATI) Subscription. This subscription service provides bi-weekly updates of the latest application protocols and attacks for use with Ixia platforms, helping you maintain a safer, more productive network.