CAVEAT CLICKER:

Adobe PDF and Trojan Horses

by Gisle Hannemyr

PDF is among other things marketed as (and used as) a presentation format for the Web. This has made me concerned about the level of protection the PDF format provides against the spreading of computer viruses and so-called "Trojan horses" (malicious commands embedded in documents).

Searching through Adobe Technical Notes and FAQs, etc. on PDF and Adobe Acrobat I was surprised that I could not find anything on the subject. There seemed to be a lot of concern regarding the integrity of the PDF-format -- but nothing on computer viruses and "Trojan horses".

Asking Adobe Technical Support about this resulted in the following (at least on the surface) reassuring answer:

While postscript provides a way to program a printer (ie. within the limits of what a printer can do), PDF does not support embedding of postscript commands. Since the postscript language is designed to control a printer, common resources that are used by "Trojan Horse" type of programs are not available. While it is possible to write a postscript file that would cause a printer to go into an endless loop, resetting the printer would remove the loop and the printer would return to "normal".

The first noticable thing about this answer is that it does not say anything about what happens when Postscript is turned into PDF.

This is done with a product knows as Adobe Acrobat Distiller. The Postscript code (including any "dangerous" operations) is fed to Distiller and is executed by the program in order to create the PDF file.

Examine the two small Postscript programs below. If you are not familiar with Postscript, just note that the first creates a file named "trojan.exe" containing the string "Distiller created this". The second deletes a file named "victim.tmp".

   %!
   (trojan.exe) (w) file (Distiller created this.\r\n) writestring
   showpage
   %%EOF

   %!
   (victim.tmp) deletefile
   showpage
   %%EOF

The first example will also overwrite any existing file with the same name without making too much fuss about it. On an operating system that doesn't protect system files this can be exploited to replace system files with virus infected version of the same.

As noted in the answer from Adobe, Distiller does not embed the Postscript commands in the PDF. Even if the original Postscript contains "dangerous" commands like those above, these are not present in the PDF. Hence, Postscript programs like the two above is only a problem for publishers and others who accept and execute Postscript programs from unknown and dubious sources. So far so good.

Unfortunately, it does not end there. While Adobe does not embed "dangerous" Postscript in PDF-files, the company has instead augmented the PDF-format with extension hooks which make it possible to embed and execute any legal command on the target system from within a PDF-document. This makes PDF-documents suitable for waging "Trojan horse" attacks.

Acrobat As a "fix", newer versions (from ver. 3.01) of Adobe's Acrobat Reader on the Microsoft platform will pop up a dialogue box like the one shown on the right.

This certainly is an improvement compared to older versions of Acrobat, where users got no warning about what the consequences of hitting a button would be -- but is it good enough for use on the World Wide Web?

In my opinion: "No". The dialogue box approach used by Adobe makes security contingent upon users having the knowledge and ability to make intelligent decisions when confronted with dialog boxes.

Aside from the fact that many users may not understand the meaning of the phrase "Acrobat is about to launch this application" or that users who has lived all their life in an GUI environment may not be very adept in understanding shell semantics (particularly if some effort is put into obfuscating the syntax), there are many ways for an attacker to create an incentive for a user to push the "Yes" button. Promise of money and sex has always worked well on a certain segment of the population, and one could also set up a trap where the user has to respond "Yes" to a suitable number of "harmless" introductory dialogue boxes (each followed by a suitable reward) to condition clicking "Yes" into a reflex before springing the trap.

After witnessing user behaviour in similar situations, I would also think that there would be a number of users who at one point in the introductory phases of the trap would become sufficiently annoyed with having to keep hitting "Yes" to go for the "All" option.

If someone want to question my motive for putting this one the web rather than letting it remain a "secret" -- let me just respond that I believe that "security through obscurity" simply do not work. Users need to be informed about the existence of this security problem in order to be prudent when confronted with dialogue boxes that request authorization to run external commands.

I also believe that Adobe should be less evasive about this. They should at least spell the problem out clearly in their user documentation and security FAQ. It would also would help a lot if the "Acrobat is about to launch this application" dialogue box pointed out that clicking on "Yes" or "All" may cause harm to the user's computer system.

What I ultimately want is the Acrobat Reader by default to be set up to browse documents on the web in a secure and restricted environment, similar to the "sandbox" the JVM provides for Java applets.

In my opinion: Unless Adobe significantly improves the security of the PDF-format and Acrobat Reader, PDF has nothing to do on the Internet, and should only be used as an in-house/intranet/extranet tool.

Acknowledgment

Thanks to Bjørn Brox for first demonstrating the security problem with embedded commands in the PDF format to me.

To view the PDF Trojan horse demonstrator, click here.