Adobe Reader Blog

Today, we announced the availability of Adobe Reader and Acrobat 9.3 and 8.2. For more information regarding the security details in these releases, please see Security Bulletin APSB10-02.

As mentioned in a previous blog post titled Adobe Reader and Acrobat Updates Include New Security Improvements, we have been shipping a new "beta" updater technology in a passive state since our October 13, 2009 quarterly update. The purpose of the new updater, once activated, is to keep end-users up-to-date in a much more streamlined and automated way. Today, we are testing the new updater with a subset of our end-users, who previously signed up for the beta program. This is the first time we've exercised the new updater with "official" updates, which allows us to test a variety of network configurations encountered on the Internet in order to ensure a robust update experience. Over the next few weeks, we will be analyzing the test results and will continue communicating important details with you, including when we expect it to be active for all users, which could be as soon as our next update.

We also talked about the introduction of the Adobe Reader and Acrobat JavaScript Blacklist Framework in that same blog post. The Framework provides customers granular control over the execution of specific JavaScript API calls. The purpose of the new JavaScript Blacklist Framework is to provide protection against attacks that target specific JavaScript API calls. As mentioned in Security Advisory- Adobe Reader and Acrobat, we were able to recommend this risk mitigation strategy during our recent zero-day exposure window. The JavaScript Blacklist Framework worked as planned and we had positive feedback from customers who were able to utilize the mitigation effectively.

As mentioned in Adobe Reader and Acrobat JavaScript Blacklist Framework Mitigation for Security Advisory - APSA09-07, if you deployed the mitigation to a "non-locked down" area, Adobe will automatically reset the Blacklist Framework with the 9.3 and 8.2 updates. But, if you deployed the registry key setting to a "locked down" area, then you will need to reset that value yourself.

Finally, as described in an earlier post, Adobe Reader and Acrobat Version 7 End of Support, support for Adobe Reader and Acrobat 7.x (as well as Adobe Reader UNIX 8.x) has ended, and Adobe strongly recommends updating to newer versions.

As stated in the Adobe Support Lifecycle Policy, Adobe provides five years of product support from the general availability date of Adobe Reader and Adobe Acrobat (Windows and Macintosh - Note: Adobe only supports the most recent major version of Adobe Reader for UNIX Version 9.x). In line with that policy, support for Adobe Reader 7.x and Adobe Acrobat 7.x will end on December 28, 2009.

End of Support
End of Support means that Adobe will no longer provide technical support or distribute runtimes, including product and/or security updates, for all derivatives of a product or product version (e.g. localized versions, minor upgrades, operating systems, dot and double-dot releases, and connector products).

Recommendation to Customers/Users
Adobe strongly recommends that customers update to the latest versions of Adobe Reader at: http://get.adobe.com/reader. By updating installations to the latest versions, customers benefit from the latest functional enhancements and improved security measures.

Special Considerations
Adobe recognizes that some organizations still require Adobe Reader 7 for use in controlled environments. Therefore, Adobe is providing a grace period of three months, until March 31, 2010, during which time Adobe Reader 7 will remain available for those customers from the Adobe Reader Download Center at: http://get.adobe.com/reader.

Additional Resources
For more information on the Adobe Support Lifecycle Policy, visit: http://www.adobe.com/support/products/enterprise/eol. For a complete list of Adobe products and technical support periods covered under the policy, visit: http://www.adobe.com/support/products/enterprise/eol/eol_matrix.html.

An Adobe Product Security Incident Response Team (PSIRT) blog post discussing the end of support for Adobe Reader 7.x and Adobe Acrobat 7.x can be found at: ttp://blogs.adobe.com/psirt/2009/10/second_quarterly_security_upda.html.

In conjunction with the release of Adobe Reader 9.2 and the announcement of Adobe LiveCycle ES2, Adobe Labs is hosting a new automated testing solution for Adobe Reader based on integration with Hewlett Packard Quick Test Professional - Adobe PDF Test Toolkit. We've created this technology for our enterprise customers to support automated testing and validation of PDF Forms workflows, including those hosted by LiveCycle ES2 and SAP.

The Reader integration with HP Quick Test Pro is similar to the existing Flex integration with Quick Test Pro (see: http://livedocs.adobe.com/flex/3/testing_with_QTP_flex3.pdf).

Adobe PDF Test Toolkit supports the following:

• Testing of PDF Forms (Acroforms and XFA forms - including dynamic forms) with Acrobat or Reader running as standalone applications or inside of a browser.


• Testing of complete form workflows with Acrobat or Reader and LiveCycle ES or SAP Interactive Forms by Adobe.

Based on customer feedback, we focused on PDF Forms workflows. We are excited by this technology and the opportunity to integrate Reader and PDF Forms into enterprise testing workflows. As an Adobe Labs technology, it should be considered an early preview and we'll be taking all feedback into consideration when planning future versions.

Today, we announced the availability of Adobe Reader and Acrobat 9.2, 8.1.7 and 7.1.4. For more information regarding the security details in these releases, please see Security Bulletin APSB09-15.

In order to strengthen protections for customers using our products, we are constantly engaged in security improvement efforts. This includes better security controls within the product itself, as well as methods to rapidly protect end-users against quickly evolving threats by reducing the window of exposure to new vulnerabilities.

As of today, Adobe Reader and Acrobat 9.2 and 8.1.7 are shipping with a new "beta" updater technology, which will initially be in a passive state. We're delivering it to end-users as part of today's updates in this state so that we can enable a follow-on, invite-only, external beta program. Even though the new updater ships in a passive state, we have the ability to selectively activate it for end-users invited into the beta program, which will allow us to test a variety of network configurations encountered on the Internet in order to ensure a robust update experience. The purpose of the new updater, once it is active, is to keep end-users up-to-date in a much more streamlined and automated way. As beta testing progresses, we will continue to communicate pertinent details with you about the new updater, including when we expect it will be active for all users. If you are interested in joining the beta program, leave a comment to this blog post stating so.

Also added to the products, as of today's Adobe Reader and Acrobat 9.2 and 8.1.7 updates, are two new changes in security user interface and control. We are moving more security awareness into the gold bar, which runs across the top of the document in the application chrome. In the past, if JavaScript had been disabled in the product, a dialog box would alert the end-user and provide further options. Now, when JavaScript is disabled, the gold bar will alert the end-user and provide further options. Our research has shown that this is a much friendlier and more effective way to interact with end-users on security matters. For more information, please see: CPS ID 50432.

Lastly, we have introduced the Adobe Reader and Acrobat JavaScript Blacklist Framework. The Framework provides customers granular control over the execution of specific JavaScript API calls. The purpose of the new JavaScript Blacklist Framework is to allow Adobe to protect customers against attacks that target a specific JavaScript API call. In this case, end-users and administrators can add that JavaScript API call to the blacklist, and block it from executing. Organizations can even block specific JavaScript API calls and keep their end-users from overriding that decision. For more information on the JavaScript Blacklist Framework, please see: CPS ID 50431.

Today, we announced our membership in the Software Assurance Forum for Excellence in Code (SAFECode). SAFECode is a non-profit organization exclusively dedicated to increasing trust in information and communications technology products and services through the advancement of effective software assurance methods. We joined other software industry leaders EMC Corporation, Juniper Networks, Inc., Microsoft Corp., Nokia, SAP AG and Symantec Corp.

As a SAFECode member, Adobe will collaborate with subject matter experts to identify and share proven best practices for software assurance, promote broader adoption of software assurance best practices into the cyber ecosystem, and work with businesses, governments and critical infrastructure providers to leverage these practices to manage enterprise risks. Adobe will take an active role in current SAFECode projects that address secure development methods, software integrity in the global supply chain, and the measurability of software security.

For more information on SAFECode, see: http://www.safecode.org.