The getAnnots Doc method in the JavaScript API in Adobe Reader and Acrobat 9.1, 8.1.4, 7.1.1, and earlier allows remote attackers to cause a denial of service (memory corruption) or execute arbitrary code via a PDF file that contains an annotation, and has an OpenAction entry with JavaScript code that calls this method with crafted integer arguments.

The impact of this flaw increases exponentially because of Acrobat’s wide deployment.  The Portable Document Format (PDF) associated with Acrobat is nearly ubiquitous, and the Reader version is included with nearly every OS downloadable off the Internet, bought in stores, or pre-loaded on shipping systems.  Plus, it’s a standard IT deployment in corporate desktops.   This vulnerability touches them all: Windows, Linux, Mac, Solaris and other Unix variants, and as mentioned earlier, practically every version and release of Acrobat.  

This is not the first time Adobe’s best known product has faced this type of publicity.  A February 2009 flaw, also designated by Adobe as critical, was finally patched March 18th.  That flaw only affected versions 7, 8, and 9.  Numerous other flaws have been found in the past.

One big fear?  Not that this will result in an increase in the number of “zombies”, or computers controlled remotely that form the basis of so-called botnets, which will happen.   But more importantly the directed or fully targeted attacks on corporations and their privately held information.  The recently released, 2009 Verizon Data Breach Report cites 72% of attacks are either directed or fully targeted, where attackers select an entity in an effort to compromise machines within the institutional environment.  This could imply further attacks and breaches in the financial sector, such as those perpetrated against Heartland Payment Systems,  the medical community, like the recently announced 8M+ Virginia Prescription Monitoring Program records currently held for ransom, or even public utilities such as the US power grid.

Another consideration – software built on or around Acrobat.  In the security world, the National Security Agency created a product called NetTop, meant to allow simultaneous connections to multiple classified networks.  Thin client implementations of this sort of multi-level desktop existed within government contractors’ repertoire’s for quite some time, but the NSA’s NetTop took it one step further.  Information could be processed between the levels, creating something called a Cross Domain Solution (CDS).   The processing between the NetTop CDS levels would be handled by separate privileged applications based on COTS products.  

One of the products chosen – a seemingly benign, older version of Adobe Acrobat without all the bells and whistles – albeit probably adjusted and renamed past recognition.  The JavaScript processing vulnerability is probably not even exploitable on the NetTop system because of numerous mitigations such as likely security policies and best practices installation defaults.  But without an enterprise traceability matrix documenting how specific requirements are met, many people might overlook such a nested installation of a program within a product and not even put it on the list to be tested.  This is a great example of how wide our security and privacy processing net must be cast, the amount of detail necessary to detect a problem, and how far consequences may reach.

As far as the Acrobat vulnerability goes, Adobe’s instructions are:

To minimize the risk until an update may be found, disable JavaScript following the instructions below:

1. Launch Acrobat or Adobe Reader.
2. Select Edit>Preferences
3. Select the JavaScript Category
4. Uncheck the ‘Enable Acrobat JavaScript’ option
5. Click OK

A simultaneously announced similar flaw dealing with javascript and the Custom Dictionary appears to affect a much smaller grouping of Adobe Acrobat products.  That flaw has yet to be confirmed by Adobe, but only targets Acrobat Reader 8.1 and 9, and should be mitigated through the same disabling of JavaScript.