Vulnerabilities in Adobe Reader underline benefits of PDF sandboxing

Control Your Own Destiny or Someone Else Will” is perhaps one of the most relevant quotes for cyber security, of course from celebrated GE CEO Jack Welch. It’s never been more true than with the PDF file format.

There has been some further coverage this week about the vulnerabilities affecting Adobe DC and Reader DC. A whopping 44 vulnerabilities were addressed in the February updates from Adobe, of which 43 are critical. Some of the vulnerabilities allow code execution, while others bypass security controls, and yet other facilitate the theft of password hashes.

Most SMEs install Reader DC and Adobe DC, and a large number of them install Reader DC as the primary viewer for PDF attachments.
But by using such a file association, it can directly expose endpoints to exploitation attempts through malicious PDFs. In some cases, by the time the PDF has been opened in the targeted software package, it can be too late.
This raises risks of sophisticated exploitation attempts by phishing attackers, who may be able to successfully deliver a PDF payload right into the organisation over email. That’s not so far fetched – email security filters provide good to excellent protection, but will not provide total protection. Compounding the problem, PDF ranks as one of the top five maliciously-used file attachment types in malicious email, so it pays off to handle it correctly.
What can be done to protect against these kinds of threats? The best option is to use a less feature-rich viewer for PDF attachments. In most cases, PDFs are used as a static document format to discourage modification. More elaborate features such as JavaScript are not used very often. So it can be a smart move to use an alternative default viewer for PDF files, and the option of choice is usually Google Chrome. A PDF viewer is contained within Chrome that provides a good level of isolation from the user environment to make it a popular choice. Chrome treats web content as untrusted and isolates it within a sandbox using the PDFium module as a viewer for PDFs, a module that has a relatively small attack surface based on known vulnerabilities and functionality.
Though PDFium is not without it’s own history of vulnerabilities. In 2016 CVE-2016-1681 showed a malformed JPEG2000 image, embedded in a PDF, could achieve code execution on the endpoint. The vulnerability was present in the OpenJPEG library that was used by PDFium to handle JPEG2000 files. It was swiftly rectified by Google with a patch being issued.
At face value, the low number of vulnerabilities in Chrome’s PDF viewing solution suggest it’s a superior approach for viewing PDFs. It certainly reduces risk, on account of the reduced functionality available in PDFium, and this is the most tangible security benefit.
The fact the Chrome PDF vulnerability sat not within PDFium, but within the OpenJPEG codec dependency, and both of these dependencies were open-source, does potentially underline the reduced control Google had over the situation. In reality it turned out Google had a patch issued quickly, though it does highlight the importance of evaluating the supply chain underlying a product and whether that fits within corporate risk appetites.
Google Chrome is therefore a sensible application for PDF file viewing, and should be configured as the default application for PDF viewing.
Other countermeasures should reflect a sensible blend of preventative and detective technical capabilities. Inbound email should be filtered, and ideally analysed by a content-inspecting scanner at the boundary. Endpoint AV and anti-malware solutions are also a must. Attempt to disrupt any endpoint compromise by investing in least-privilege firewall rulesets and a mandated web proxy with dynamic blacklist updates. So, in the event something malicious does get a foothold on your endpoint, it has to interact with a detective and preventative control in the form of a good web proxy.