When it comes to embedding PDF rendering and viewing capabilities in commercial-grade applications, developers often consider PDFium -- a native open source PDF library and Chrome’s PDF rendering engine. Today, PDFium is used in countless applications as well as a few PDF Software Development Kits (SDKs).
Since being open sourced in 2014, however, PDFium has had 88 major vulnerabilities reported within the Common Vulnerabilities and Exposures (CVE) database. This is roughly 1.5 new vulnerabilities for each month of every year since PDFium’s release. (Enough for ThreatPost Deputy Editor-in-Chief Tom Spring to label PDFium “problem-plagued”.)
The high number of reported PDFium vulnerabilities compared to some PDF libraries doesn’t necessarily imply an unusual degree of insecurity for open source; but it creates challenges for developers, DevSecOps, and security teams.
Indeed, while Chrome users receive critical PDFium security fixes automatically, those who embed PDFium directly or indirectly in apps may go months or even years before manually updating. During that time, they leave their organization and their end-users exposed to possible attacks, and developers may not even be aware of the risks.
This article is intended to help you manage PDFium vulnerabilities. We answer: what security challenges does PDFium face today? And what can you do to protect yourself now and down the road?
The now infamous Equifax breach and other high-profile open source security bugs like Heartbleed heightened awareness about the need to get a handle on and secure open source components used in business-critical applications. And since 2014, open source has seen an influx of attention and contributor enthusiasm, as well as tech giant funding -- all directed towards putting more eyes on popular open source code.
Today, initiatives like Google’s Project Zero along with more generous bug bounty programs entice security analysts and ethical hackers to pore over open source libraries for security flaws. Their efforts have contributed to a spike in the number of reported open source vulnerabilities, which skyrocketed over 50% in 2017 compared to 2016, with most growth concentrated in popular open source libraries like PDFium.
While instrumental in helping to secure software against the likes of criminals and state-sponsored hackers, the increase in reported open source vulnerabilities poses a challenge for IT professionals tasked with securing their application(s). Hackers will scour the same public repositories and issue trackers seeking ready-made attacks that offer a good return on investment. Every time a new open source vulnerability is announced, therefore, organizations are essentially engaged in a race to defuse a ticking time bomb in their code.
~Apache Struts Sept. 2017 Statement on Equifax breach
This race to defuse new bugs is especially pronounced in PDFium due to its use in Google Chrome. PDFium vulnerabilities instantly become front-page news, sending up a signal flare for hackers who seek out easy targets.
Anyone who uses PDFium directly or indirectly through an SDK will not be hard to find. Hackers can search Google for the PDFium open source copyright disclaimer in the T&Cs -- a requirement of the PDFium licensing agreement. They can also leverage other tricks when searching the code as well as third-party services to identify apps with a specific library or PDF SDK in seconds.
Therefore, anyone who embeds PDFium directly, or indirectly via a PDF SDK is at risk.
To find out whether a library embeds PDFium, you can search their website or T&Cs for the PDFium copyright disclaimer. You can also contact a PDF SDK vendor directly if you are uncertain.
The PDFTron SDK, for example, does not use PDFium or any other third-party PDF library for its core rendering engine; instead, the PDFTron engine is built entirely from the ground up.
Eight high/medium severity security exploits have been identified in PDFium so far in 2019, including the most recent in late October. The latter high-severity vulnerability could have allowed a hacker to inject a malicious payload and hijack control over an application.
Browser, android, iOS, and UWP apps are generally sandboxed to prevent an attacker from taking control over the entire device. Nevertheless, an adversary could still scoop sensitive data located inside the app (e.g. emails, phone numbers, SSNs, SINs, banking information, etc.) or even the document itself.
In contrast to mobile apps, server-based applications are not sandboxed -- so an adversary could take control over the server via PDFium.
New PDFium vulnerabilities are generally logged in the industry-standard repository for publicly released software -- the Common Vulnerabilities and Exposures (CVE) database, maintained by the MITRE Corporation and supported by the US Department of Homeland Security.
Since its publication in 2014, PDFium has seen 88 vulnerabilities reported to and accepted within the CVE. And the frequency of newly reported vulnerabilities does not appear to be slowing down greatly after accounting for a 2016 activity spike.
These figures ultimately do not encompass every PDFium vulnerability ever disclosed publicly. Some fly under the radar within Google’s bug tracker, where security flaws tend to be first reported. Since this repository is geared towards bug fixing and not vulnerability reporting, contributors will not clearly label all PDFium vulnerabilities as such. PDFium vulnerabilities may therefore be poorly indexed and difficult to search. This may complicate your efforts to keep on top of new threats. But information will still be accessible to hackers willing to dig into and follow conversation threads.
Our developers have also encountered several instances of security holes being fixed but not being filed in the CVE.
Additionally, PDFium contributors, who may not be PDF experts, have been found to introduce security vulnerabilities via regressions when refactoring code or fixing older flaws. Given ongoing quality control issues, it is unlikely that the frequency of newly announced PDFium vulnerabilities will diminish significantly in the foreseeable future.
PDFium security vulnerabilities receive higher-than-average severity scores in the National Vulnerability Database (NVD) commonly used by teams when prioritizing their response and remediation efforts.
Note: Comparison uses Common Vulnerability Scoring System v3.0, introduced circa 2016.
Due to PDFium being in native “memory-unsafe” C++, most PDFium vulnerabilities involve exploitation of a memory corruption or error and thus receive higher severity scores. These weaknesses are considered highly dangerous because they are generally easily detectable (e.g., via fuzz testing) and easily exploitable, and carry significant risk for impacted organizations. They are similar in nature to Heartbleed which exploited a CWE-126: Buffer Over-read weakness (CVE-2014-0160) in the Open SSL Heartbeat Extension.
PDFium vulnerabilities are also well-represented among the CWE’s top 25 most dangerous software errors. This demonstrative list was put together by the MITRE Common Weakness Enumeration (CWE) team to try to provide an objective data-based model of what types of software errors lead to the most damage in the real world in 2019 -- rather than just relying on surveys or opinion.
The exact formula used to create the list is available on the MITRE CWE website, an encyclopedic resource for known software weaknesses. Put crudely, the top 25 list formula combines the frequency by which a weakness appears plus its average NVD CVSS severity score to calculate an overall danger rating. The most common types of vulnerabilities in PDFium top the list, which is significant as the CWE has over 600 cataloged weaknesses.
Reported Issues in PDFium among the CWE’s top 25 most dangerous security flaws:
- #1 Most Dangerous: Improper Restriction of Operations within the Bounds of a Memory Buffer (CWE-119) -- 25 of 88 CVE-reported PDFium weaknesses
- #5: Out-of-bounds Read (CWE-125) -- 5/88
- #7: Use After Free (CWE-416) -- 26/88
- #8: Integer Overflow or Wraparound (CWE-190) -- 8/88
- #12: Out-of-bounds Write (CWE-787) -- 5/88
The fastest way to determine one’s level of exposure will be to read the security analysis, usually referenced within the related National Vulnerabilities Database (NVD) entry. (You can also try contacting your PDF SDK vendor for further information.)
However, it may not be clear immediately from the analysis how long the PDFium vulnerability existed or if it has been exploited in a real-world attack.
The security analysis may also be withheld for a 60-day grace period. Google, for example, commonly imposes an embargo. In a public statement related to an Oct. 2019 high-severity vulnerability in PDFium, Google said:
You may have to delay your vulnerability remediation process until after an embargo is lifted.
Companies who directly embed PDFium in their application(s) will have to manually update to close a security hole historically about every other month. Those who embed a library that uses PDFium in it will first have to wait on their vendor to update their library, and then update their code.
If you’re using a commercial PDF SDK, contact your vendor to find out how to update (or if you need to renew your maintenance subscription first).
Updating and testing your PDFium-based app every month or whenever vulnerabilities are announced (usually every other month) should provide a modicum of security. However, you will find this takes time from other priorities, as devs will be required to drop everything and respond quickly. And the costs are even higher once one considers that more experienced devs are usually the ones tasked with remediating open source vulnerabilities.
On top of that, PDFium is popular open source and thus widely deployed, and apps embedding PDFium will not be difficult to find; therefore, PDFium offers an attractive target for hackers seeking a high ROI, as they will not need to understand each target’s full code base to be successful. Using PDFium, therefore, you will always face a degree of insecurity.
Should you require additional protection and/or wish to free up dev resources, you might consider a professional-grade commercial PDF SDK. Unlike open source, closed-source code for the rendering engine is not readily available -- in practice, offering a significant deterrent.
For example, as of writing, there are no known vulnerabilities in the PDFTron SDK. (Check out our article to learn more about how we secure the PDFTron SDK .)
We hope this article was helpful! If you have any feedback or questions, don’t hesitate to contact us .