An Analysis of PDF Reader Security

By Jess Beckwith


PDFs rank among the most popular file types used by laymen in today’s Internet.  First introduced by Adobe in 1993, it is an all-too familiar method of sharing standardized documents across a wide variety of systems, such as from Windows to Mac.  Fillable forms, reports, books, and many other types of organized information are all impacted by the PDF.  But since its inception, PDFs have provided a different type of shared information: malware.  In this blog, we will be covering a case study of how a vulnerable PDF reader responded to a case-study malicious PDF over a decade ago, then investigate how modern PDF readers compare in their defensive capabilities.

Case Study: Pidief

Back in 2007, a PDF malware family known as Pidief was discovered out in the wild.  Like most PDF malwares, it requires a level of user interaction to actually cause damage to a victim’s computer.  It was not the first well-known instance of malicious PDFs (that was the Peachy worm in the very early 2000s), but it is distant enough for comparisons to be drawn.  According to a SANS article by Joel Yonts, the basic infection pattern of a malicious PDF is as follows:

  1. Social Engineering
    1. Delivery: the malicious PDF is sent to the target (email, website download, etc)
    1. Opening: the target is manipulated to open the PDF
  2. PDF Dynamic Content
    1. Trigger: the “Open Action” PDF object triggers a script within the PDF
    1. By-Pass: the vulnerability is exploited via the script, allowing a bypass of PDF viewer security functions
    1. Preparation: the script either downloads malware from the Internet or extracts it from an imbedded PDF object
  3. Malware Installed
    1. Execution: the received malware is executed on the target system automatically

In the case of Pidief, when the PDF is first clicked on to be opened, a pop-up window appears to explicitly warn the user that the file is unsafe, but still gives them the option to open it anyways.  Should an ignorant user decide to click “Open”, the infection process continues, following the pattern described above.  For a full technical breakdown of the infection process, pre-malware execution, see the referenced article.

In this context, PDFs are just the delivery system for different malwares.  The PDF itself cannot hurt you: it’s what the PDF reader may do or fail to do that can.  When preparing to open a PDF, often it is the nature of the PDF reader’s security that will either indicate that an infection is about to take place or leave the fate of the computer up to the end user.  The critical moment of this style of PDF exploitation is that choice to click “Okay” by the user.  So how do modern PDF readers help the user to make that decision?

The remainder of this blog will look at two modern PDF readers and see how they hold up against modern threats, and whether they likewise offer that same amount of end user support against potentially malicious PDFs.  In addition, some potential strategies to overcome these security settings will likewise be discussed.

PDF Reader 1: Adobe Acrobat Reader DC

How do they handle PDF security?

Adobe offers a high level of customization and two main levels of control when it comes to the security of their PDF readers: individual-level and administrator-level.  For information security, they have several portable security policies that can allow or prevent certain users from opening or editing a PDF.  For security against malicious PDFs, they provide documentation for security warning settings.  They provide specific examples of when their security warning dialogs are triggered, such as JavaScript (blacklisting, handling execution), stream objects, form fields and web links.  They also maintain regularly updated databases of patched vulnerabilities.

How well does it work?

Overall, the fact that Adobe contains so much information and fine-tuning for their security settings should not come as a surprise.  They invented PDFs, after all.  However, when it comes to how useful these security settings are, one must consider the two primary targets in malicious PDF attacks: individuals and organizations. In general, organizations are more likely to have other overhanging security systems in play than individuals (especially laymen), such as network IDPSes, developed firewall rules, widespread anti-malware software, and plain old policy.

According to CVE Details, up to 2018 there are 681+ reported vulnerabilities, the most common of which are as follows: 67.8% Code Execution, 44.3% Overflow, and 31.6% Memory Corruption.

Some methods of attack to overcome their security settings are described below:

  • Blacklisted JavaScript:  Adobe maintains a blacklist of known JavaScript vulnerabilities that will warn the user if a PDF tries to access it.  This includes JavaScript APIs.  The solution to overcoming this is the same as overcoming the signature-based functionality in IDS/IPSes: avoid using well-known JS vulnerabilities, or stick to only the most recent vulnerabilities.
  • Accessing Stream Objects/Inserting Data/Web Links: This comes down more to the application settings where Adobe’s security warning dialogues can be found.  Changing these may require some level of social engineering (i.e., “This is the security team, we require this setting to be disabled to run some quick tests”, or it is just a matter of scripting the disabling process before any of the more questionable data may be accessed by your malicious inject.
  • Administration-based Policies:  Sometimes, a user will simply be too low-level to choose whether to trust a PDF, which will never allow the embedded script to run.  The power offered to administrative bodies for security purposes is quite potent.  So, to overcome these policies, there are two main approaches without straight up exploiting a weakness in these policies:
  • Bottom-Up:  If you can perform privilege escalation on the low-level user’s terminal, you could potentially by-pass these restrictions and return the choice to the user whether to trust a PDF. Or, depending on the level of privilege acquired, you could disable that choice/warning dialog altogether!
  • Top-Down:  This is more systematic and would most likely require more effort, but it could leave every machine on the system with vulnerable PDF readers.  If you can manipulate the administrative servers (social engineering, changing registries à “Adobe Experience Manager – Forms Server”, Group Policies), you could cause system-wide changes to their security policy, thus opening the way for further attacks.

PDF Reader 2: Foxit Reader

How do they handle PDF security?

Although their documentation and list of features are not nearly as extensive as Adobe’s, Foxit does still provide additional unique security options for their users.  Some additional options may be found here as well, but nothing akin to the numerous pages of online documentation that Adobe has. These boil down to five main options:

  • Security Warning Dialogs – like before, it warns a user if a PDF shows suspicious activity
  • Trust Manager/Safe Mode – instead of warning users, it will simply block a PDF’s suspicious call/external command
  • ASLR (Address Space Layout Randomization) – randomizes memory addresses for storing sensitive key file information
  • DEP (Data Execution Prevention) – does not allow code from non-executable memory locations to be run
  • Disable JavaScript – limits functionality of Foxit Reader tools in exchange for security

How well does it work?

Like Adobe, Foxit provides security warning dialogs (+ safe mode) to prevent a user from accidentally triggering malware in a malicious PDF.  They seem to cover much of the same basics as the PDF readers from Pidief’s day.  However, their options for controlling JavaScript are limited to “on or off”, versus Adobe’s wider range of fine-tuned specifications, which could leave them exposed to more JS-specific attacks.

When it comes to administrative control, it is compatible with Windows’ GPO functionality, much like Adobe.

According to CVE Details, up to 2019 there are 300+ reported vulnerabilities, the most common of which are as follows: 90.3% Code Execution, 14.3% Gain Information, and 9.0% Denial of Service.

Some methods for overcoming their security settings are described below.

  • Administration-based Policies:  The attacks described in the Adobe section would likewise apply here and would require about the same amount of knowledge and effort to perform.
  • JavaScript:  With Foxit, the ability to use JavaScript is tied to their tools, like form filling.  If one is either able to manipulate a called JavaScript API, or they can target Foxit’s tools with their script, their oversight could open a whole range of vulnerabilities.  They do not seem to keep a blacklist of JavaScript vulnerabilities, or at least it is kept hidden by their Trust Manager.
  • Trust Manager/Preferences:  Foxit’s Trust Manager contains the functionality to allow specified apps to access PDFs without valid digital signatures, as well as XML Files.  The list of trusted apps can also be found (by default) within Windows at C:\Users\Public\Foxit Software\Foxit PhantomPDF\Trust App.xml.  Manipulation of either of these functions could produce some promising results in avoiding user suspicion.


Malicious PDFs may not be recognized as the highest priority in terms of global cybersecurity, and that is due to one simple reason: the approach will almost always rely on social engineering.  No matter how insecure a PDF reader is, or how complex a malware is to gain different levels of access or information, the PDF must be opened by an end user for any of its embedded software to run.  The feasibility of some of these attacks may be far-fetched, and that is to be expected.  However, no amount of exploitation within embedded PDFs will ever amount to anything if the PDF is never opened, and with the correct configurations, the likelihood of that happening reduce significantly.

Ultimately, the human element is the greatest vulnerability of PDF readers, and as silly as it may seem, those dialog boxes warning users about potential dangers could be the difference between security and suffering.  Based on the research performed above, the PDF readers of today most certainly contain the tools necessary to help even a less educated user avoid triggering an infection on their system.  However, the way they are configured will also hold a significant impact, and companies that produce PDF readers must ensure that these configurations (especially their defaults) are set with that optimal security in mind.

Reference (in order of appearance)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s