Tuesday, April 28, 2009

PDF and JavaScript - Strange Bedfellows

When the latest word on Adobe's problems with Acrobat came down[1,2], recommending people to "turn off JavaScript in Adobe Acrobat" I admit I was curious, like everyone else, why JavaScript was even in PDF files in the first place.  Over the last several months going back to last year, we've started reading about Adobe's ill-fated attempt to insert JavaScript into Acrobat tools - and it begs the question - WHY?

As you can probably tell, Adobe does a pretty good idea of convincing people allowing JavaScript to run inside Acrobat is a good idea... selling its functionality to feature-hungry PDF developers...
"...you can customize the behavior of a particular PDF document, implement security policies, interact with databases and web services, and dynamically alter the appearance of a PDF document by using JavaScript. You can tie JavaScript code to a specific PDF document, a particular page within a PDF document, or a form field or button in a PDF file. When an end user interacts with Acrobat or a PDF file displayed in Acrobat that contains JavaScript, Acrobat monitors the interaction and executes the appropriate JavaScript code."
Investigating the matter a little further, and realizing that there are many issues inside Adobe's Acrobat product line with or without JavaScript being involved, here are some examples of seemingly insane JavaScript extensions to the PDF functionality:
  1. Global object | This object is "used to store data that is persistent across invocations of Acrobat or shared by multiple documents"; it's easy to see where this could go wrong very quickly.  The global object is subscription-based; meaning, a document must subscribe to the functionality, but we've seen many instances where a global object in other languages simply becomes abused through some exploit in the security mechanism...
  2. SOAP object | This object "provides support for rich text responses and queries, HTTP authentication and WS-Security, SOAP headers, error handling, sending or converting file attachments, exchanging compressed binary data, document literal encoding, object serialization, XML streams, and applying DNS service discovery to find collaborative repositories on an intranet"... while the intentions are good, one can certainly find interesting things to do here, especially utilizing the "exchanging compressed binary data" feature
  3. Priviliged context | According to Adobe's reference, once you explicitly state your trust for a document's signing certificate, that PDF file can then do "priviliged things" which otherwise would be disallowed.  Seriously, how hard is it to fool even an educated user to trust a digital certificate?
  4. Safe path | Safe paths are places where JavaScript can write to the local  disk... safely.  According to the Adobe documentation, "a path cannot point to a system critical folder, for example a root, windows or system directory.  A path is also subject to other unspecified tests."  Unspecified tests?  So Acrobat controls where the PDF (via JavaScript) can read/write?  If this is anything like the old IIS ../../../ issues, I can only imagine the fun.
The point here is this... JavaScript interpreters have notoriously been... buggy... to say the least and there is a lot of damage that Adobe could be doing here without really considering the consequences.  It's irrisponsible to randomly add functionality to a file format and rendering engine without first considering the serious consequences.  Did Adobe think about the millions of users who use Acrobat to read/write PDF files every day?  Of course you and I would hope so... but we can't assume.  Adding powerful functionality like JavaScript into the PDF file format and interpreter has clearly caused some serious damage... just Google "Adobe PDF vulnerability" yourself (or click here for results).

Adobe needs to answer the main question looming over this JavaScript functionality disaster - "Was JavaScript added because developers and designers demanded it?  Or was it simply another example of a vendor throwing in cool functionality to lure developers to use their product?  Adobe, we're listening...

[1] TheRegister Article - April 28th, 2009
[2] Adobe PSIRT Blog - April 28th, 2009

2 comments:

John Dowdell said...

I don't know, but it looks like JavaScript was added back in 1996:
http://en.wikipedia.org/wiki/Adobe_reader#3.0

jd/adobe

Thom Parker said...

I think you've missed the point. To start off, Scripting was added to Acrobat in version 3 in order to support interactive form fields. You know, things like calculations so people could create order forms. But scripting is really useful stuff, not just for forms, but also for automating document workflows, so it's been massively expanded over the years.
But Adobe is nothing if not paranoid, so secondly, none of the featurs you list pose a security problem. Your comments show that you were just guessing when you chose these items without understanding how they work. The real threat, and the boneheaded bug on Adobe's part, is internal to the Acrobat's implementation fo the JS Engine.

It's bugs in the product implementation that create the security problem, not product features. The Acrobat JavaScript environment by itself is way more secure than any browser or OS that users interact with on a daily basis.

Thom Parker
WindJack Solutions

Google+