Escaping the sandbox: When PDF and Windows exploitation meet

May 16, 2018

In recent blog posts, we’ve discussed numerous malicious remote-code execution techniques hackers have been discovering – and capitalizing on – in Microsoft Office documents. And we’ve frankly been somewhat shocked that new vulnerabilities are apparently being discovered all the time on a platform that is decades old.

But it turns out that Office users are not the only victims of long-embedded security problems in long-used software. PDFs – Portable Document Format files – predate even Office, and recently it was discovered that hackers have figured out a way to use specially crafted PDF documents, embedded with JavaScript code that manipulates objects in memory and triggering a vulnerability in multiple PDF readers. The vulnerability, officially called CVE-2018-4990 Remote-Code-Execution in various Adobe Readers, hasn’t been used maliciously – yet – but researchers at ESET [1], which discovered the vulnerability, say that doesn’t mean it couldn’t.

According to ESET, a slew of Acrobat Reader programs are vulnerable, including:

  • Acrobat DC (2018.011.20038 and earlier versions)
  • Acrobat Reader DC (2018.011.20038 and earlier versions)
  • Acrobat 2017 (011.30079 and earlier versions)
  • Acrobat Reader DC 2017 (2017.011.30079 and earlier versions)
  • Acrobat DC (Classic 2015) (2015.006.30417 and earlier versions)
  • Acrobat Reader DC (Classic 2015) (2015.006.30417 and earlier versions)

How does it work? Using a series of memory manipulations, the attacker is able to get read/write memory by using the embedded JavaScript code, activated when a PDF is opened. When the manipulations are completed, the hackers get what they were after  – the ability to read and write memory access from the malicious JavaScript.

Figure 1. JavaScript code to Read/Write from memory upon successful exploitation

But very much like Office’s Protected View, PDFs – when they are read using Adobe Reader software – has a security mechanism specifically designed to keep users safe: A sandbox built into the software that restricts its capabilities and executes (opens) them in a protected environment, preventing the PDF from interacting with the Windows Registry, where it could make malicious changes. Thus, users potentially should be protected from any exploits in PDFs.

Not in this case, though.

Users who view PDFs in Reader’s Protected View mode generally need to trust the document in order to pull it out of the sandbox, so they can interact with it. However, hackers have discovered a way to do that automatically, using an until-now unknown Windows vulnerability,  CVE-2018-8120.

Using sophisticated code manipulation, the authors were able to escape the applied sandbox, thus allowing for code execution(Note that while the vulnerability was not found on newer Windows systems, ESET found that it was an issue in older versions of Windows, including Windows 7 and Windows Server 2008 – of which there are still millions “in the wild”). Thus by combining both vulnerabilities, an attacker could gain remote code execution when a victim opens a PDF document on affected Reader programs and operating systems.

ESET researchers came upon this attack vector when they analyzed a PDF that was uploaded to a public repository of malicious documents. There was no active exploitation code in the document – but, say the researchers, that just means that the exploit is still at its “beta” stage, or may have been uploaded by mistake. In any event, the threat is there – and obviating it will require patches to both Reader and Windows, as the cycle of attack vector-defense-new attack vector again repeats itself – as it endlessly has for years now.

When those patches will come out is now a major concern of cyber security experts, as the fact that the exploit has been unveiled means that hackers might try to take advantage of this exploit before an antidote is developed. Thus, the ESET post could potentially motivate hackers to try and use the exploit now – making everyone who has the configuration that fits the attack vector vulnerable. Unless, of course, you’re a Votiro customer – in which case the timing and scheduling of the attack and its defenses are not an issue for you.

A PDF as described in this attack would have been analyzed by Votiro’s Disarmer, which would have extracted the offending code – deconstructing the file, removing the code that does not belong there, and reconstructing it as a valid PDF that could be read by Reader, without the risk. If you haven’t tried Votiro’s Disarmer yet – and you work with PDFs – now is the perfect time to try it.