Archive for June, 2011

Examples of Community Engagement

Recurity Launches Blitzableiter 1.0 at FIRST & Drs. Venkatakrishnan and Hamlen Awarded National Science Foundation Trustworthy Computing Grant

Recurity Launches Blitzableiter 1.0 at FIRST

Ever since a late-night conversation with Felix ‘FX’ Lindner, Brad Arkin and myself at Black Hat last summer, members of the ASSET and Adobe Flash engineering teams have been assisting researchers from Recurity Labs, the German security research and consultancy company, in their development of Blitzableiter (“Lightning Rod”). This mitigation technology filters malicious Flash (.SWF) files before they can carry out an attack against a vulnerability in the Adobe Flash Player.

Today, Recurity officially launched Blitzableiter v1.0 at the FIRST conference in Vienna (June 12-17, 2011). The Blitzableiter beta has already been used by several companies, including a large social networking site in Europe.

Blitzableiter is a signature-free, open source mitigation technology for enhancing Flash content security that uses complete format normalization instead of scanning. A potentially malicious input file is read, parsed and interpreted, applying strict rules of specification compliance.  If the input file violates those rules, it’s rejected.  After initial parsing, the original input file is discarded completely, and a new file is created based on the information obtained from the original input. Blitzableiter supports automatic modification of AVM1/2 (AS2/3) code in Flash (.SWF files) and during testing has demonstrated the ability to block almost every Flash Player exploit sample observed since 2010. It supports version SWF3 to SWF10. The 1.0 release version can be used client-side with NoScript in Firefox, or integrated with proxy servers or firewalls using an included ICAP server.

Congratulations to the Recurity team on the Blitzableiter launch! For more information on Blitzableiter, visit the Recurity Labs website at

Drs. Venkatakrishnan and Hamlen Awarded National Science Foundation Trustworthy Computing Grant

Congratulations also to Drs. Venkatakrishnan and Hamlen at UI Chicago and UT Dallas for being awarded a National Science Foundation Trustworthy Computing grant for ‘Securing Web Advertisements.’ Their project will be a combination of Dr. Hamlen’s research in Certified In-lined Reference Monitoring (IRM) system for ActionScript bytecode and Dr. Venkatakrishnan’s research on HTML and JavaScript advertisements to create a unified web advertisement security framework.

Both projects serve as great examples of members of the security community, academia and vendors collaborating to help protect customers from malicious attacks.

Peleus Uhley
Platform Security Strategist

Adobe Acrobat and Reader 10.1 Released, Feature New Security and Signature Enhancements

Just last night, we announced the availability of updates to both Adobe Acrobat and Reader, bringing them up to version 10.1.  Along with a significant list of vulnerability mitigations, these updates also bring with them substantial changes to the secure operation of Acrobat on Windows, and to the digital signature functionality across platforms.

First, Acrobat 10.1 on Windows now features the same Protected Mode operation as Adobe Reader X, protecting users from malicious PDFs.  Additional information on Acrobat’s implementation of sandboxing is available on the Adobe Secure Software Engineering Team’s (ASSET) blog.  For those savvy in digital signatures, note that Protected Mode (on both Acrobat and Reader) may impair the installation of PKCS#11-based tokens.  Refer to the simple instructions here for a workaround.

And if you’re like me and love the nitty-gritty details of digital signatures, you’ll probably appreciate the other signature-specific changes in 10.1…

Continue reading…

Some Notes on Adobe Reader and Acrobat X (10.1)

As part of the regularly scheduled quarterly security updates for Adobe Reader and Acrobat, we released Adobe Reader and Acrobat 10.1 today. The Security Bulletin and Release Notes have all the details, but there are a few points I wanted to call out in particular:

Adobe Acrobat Protected View

The first is Adobe Acrobat Protected View (aka sandboxing). This security enhancement for Adobe Acrobat extends the concept of Adobe Reader Protected Mode (introduced with Adobe Reader X in November 2010) to the Acrobat browser plugin; it also introduces Adobe Acrobat Protect View for document viewing with Acrobat in standalone mode. Kyle Randolph’s post gives more technical context, but a short-hand description is that Adobe Acrobat Protected View offers similar mitigations and user workflows to Microsoft Office 2010 Protected View. Acrobat Protected View provides an additional layer of protection for Acrobat X users and will ultimately result in a safer experience, fewer urgent patches, and lower total cost of ownership in enterprise environments.

Adobe Reader Automatic Update Option for Windows Users

The second relates to the automatic update option in Adobe Reader. In April 2010, we activated a new updater for Adobe Reader and Acrobat designed to keep end-users up-to-date in a much more streamlined and automated way. With the activation of the new updater, Windows users were given the option to download and install updates for Adobe Reader and Acrobat automatically, without user interaction. During the first phase of the roll-out, we utilized the users’ current update settings found in the Preferences because the automatic update option was a significant change to the way most Windows users were accustomed to updating their product installations. With today’s update, we are entering the next phase in the roll-out by turning the automatic update option on by default for all Adobe Reader users on Windows. Because honoring the user’s choice is important to Adobe, the user will be presented with the following screen for the automatic update option the next time the Adobe Reader Updater detects that a new update is available:










The vast majority of attacks we are seeing are exploiting software installations that are not current with the latest security updates. We therefore believe that the automatic update option is the best option for most end-users and strongly encourage users to choose this option.

Support Model Change for Adobe Reader for Linux

The third is a change to our support model for Adobe Reader for Linux. Moving forward, we will ship security updates for Adobe Reader 9.x for Linux twice a year (i.e. every other quarter). The next security update for Adobe Reader 9.x for Linux will ship with the next quarterly security update for Adobe Reader and Acrobat on September 13, 2011. This change has been made to better align our engineering investments with usage patterns and the absence of attack activity — we have never seen or heard of reports of a real-world malware sample that was functional or targeted against Adobe Reader for Linux. Going forward, each security update for Adobe Reader 9.x for Linux will address all known CVEs present in the code for that platform.

Adobe Reader and Acrobat Quarterly Update Cycle

The last point is a quick reflection on two years of regularly scheduled security updates for Adobe Reader and Acrobat. In 2009, we announced a move towards regularly scheduled updates and shipped the first quarterly update on June 9, 2009. Since then, we have received quite a bit of positive feedback on the benefits of having a regular update cadence with a predictable schedule aligned with the Microsoft “Patch Tuesday” release of security updates. We have also demonstrated flexibility in responding appropriately to security incidents with out-of-cycle updates or accelerated schedules for planned releases.

There has also been occasional confusion regarding the definition of the term “quarterly.” To us, quarterly means once per quarter, but not necessarily exactly three months apart. Sometimes, the next release may be three months out; but depending on customer feedback and engineering schedules, we may also schedule the next release two or four months out. Our goal is to keep a regular cadence for Adobe Reader and Acrobat to provide timely updates to resolve vulnerabilities reported to Adobe and to allow our customers to plan for each security update by announcing the date of the next release in the Security Bulletin for each current release.

In closing, we are excited about Adobe Acrobat Protected View in today’s Acrobat X (10.1) release, and we hope even more end-users will take advantage of the automatic update option now turned on by default in Adobe Reader for Windows. The goal behind all of this work is to focus our efforts on activities that will help protect users by increasing the real-world cost to attackers, and we believe the Adobe Reader and Acrobat X (10.1) release helps us move the needle on this important metric.

Brad Arkin
Senior Director, Product Security and Privacy

Inside Adobe Acrobat Protected View

Kyle Randolph here, along with the security team for the Adobe Acrobat family of products. This post will discuss the technical details of the new Protected View added in the Acrobat 10.1 release announced today. Even more technical details are available in the Application Security Library.Protected View builds on Adobe Reader Protected Mode discussed previously in a series of technical posts on the ASSET blog. With Protect View, Acrobat users will benefit from the protection provided by a sandbox when they open untrusted PDF files.

Design Principles

The high-level security design principles for Protected View include the following:

  • As secure as Adobe Reader Protected Mode: Acrobat leverages the same sandbox technology and implementation as Adobe Reader.
  • PDFs in a browser offer Adobe Reader Protected Mode functionality and protection, along with “rights-enabled” features: Protected View in a browser offers a similar experience to Adobe Reader Protected Mode, plus the features that are available in Adobe Reader for rights-enabled documented are always available for Acrobat Protected View users.
  • Trust can be assigned to documents so that they bypass Protected View restrictions: Because of its integration with Enhanced Security, users can specify files, folders and hosts as privileged locations that are not subject to Protected View trust restrictions. PDFs originating from a privileged location will not open in Protected View.

Standalone Application

In the standalone application, behavior is simple and parallels the Protected View provided by Office 2010. During a file download and/or save, Web browsers and e-mail programs typically mark downloaded files and attachments with a “potentially unsafe” flag. When you open such a document, Acrobat displays a warning bar at the top of the viewing window. In this state, many of the Acrobat features that interact with and change the document are disabled, and the associated menu items are greyed out in order to limit user interaction.

The view is essentially read-only, and the disabled features prevent any embedded or tag-along malicious content from tampering with your system. Once you’ve decided to trust the document, choosing Enable All Features exits Protected View, enables all menu items, and provides permanent trust for the file by adding to Enhanced Security’s list of privileged locations. The document is now open in a full, unsandboxed Acrobat process.


When a PDF file is opened in a browser, Acrobat Protected View provides a streamlined experience that doesn’t utilize a warning bar. Instead, browser-based PDF files provide an Adobe Reader-like experience for documents that have been “rights-enabled.” That is, all of the Adobe Reader features are available in addition to features that become enabled when a document author uses Acrobat to extend features to Adobe Reader users. These features include signing existing form fields, adding new signature fields, saving form data, etc.

Table 1 Protected View: Standalone versus Browser Functionality

Feature Standalone Browser
Drag-drop PDF files to the reading or navigation pane No Yes
Printing No Yes
Advanced Printing No No
Saving No Yes
Pan and Zoom No No
Loupe Tool No No
Reading Mode No Yes
Full Screen Mode No Yes


Integration with Enhanced Security

Acrobat Protected View is integrated with Enhanced Security both in the user interface as well as at the registry level. When a user chooses “Enable All Features,” the current file is added to the user’s list of privileged locations, thereby granting a level of trust which allows it to bypass the Enhanced Security restrictions. Those restrictions include such things as cross-domain access, data injection, silent printing, etc. For this reason, you should only enable all features for documents you absolutely trust.

The application stores information about privileged location trust in the registry. Once a file is trusted, a unique identifier is added to each of the cabs under the cTrustedFolders registry key. Conversely, if a file is trusted at the registry level manually or via some other feature like the Options button on the Yellow Message Bar, that file becomes exempt from Protected View from that point on.

It’s all a matter of what you trust: Protected View, Protected Mode, and Enhanced Security provide restrictions to safely open documents that you do not trust; however, you can also bypass those restrictions for files, folders and hosts you that deem trustworthy. You control the level of security you need.


The Acrobat Protected View sandboxing solution is a great way for protecting users from malware PDF attacks. In the protected view the user will have very limited access to the Acrobat functionality as such, but it’s just enough to make an informed decision as to whether he/she wants to trust the document or not. And its design allows the user to read the contents of a PDF file received from untrusted sources without having to worry about a system compromise due to malware infection. The yellow bar indicator at the top allows transition into the normal editing mode of Acrobat once the document has been explicitly trusted by the user. Sandboxing adds another layer of defense to the overall Acrobat product security. It’s not a silver bullet, but it can go a long way in protecting our customers and users from most of the commonly known attacks out there.

-Kyle Randolph, Ben Rogers, Suchit Mishra



The Latest on Adobe’s 2011 Conference Schedule

Hi there!

 Steve here, checking in to give you an update on where the Adobe product security team’s travels are taking us next.

 Brad Arkin will deliver the Thursday keynote at the 2011 OWASP AppSecEU Conference in Dublin, Ireland on June 10, 2011.

 As the Chair of I’ll be presiding over FIRST’s 23rd annual conference in Vienna, Austria, from June 12-17, 2011. The Adobe PSIRT group manager, David Lenoe, will also be in attendance.

The next stops after this will be other conferences in North America, such as REcon 2011 in Montreal, Canada, and (our favorite) Black Hat 2011 USA in Las Vegas. Bryan Sullivan’s Black Hat talk on “Server-Side JavaScript Injection: Attacking NoSQL and node.js” has already been accepted.

See you there!  🙂

Steve aka  “Cap’n Steve”  Adegbite