Author Archive: Brad Arkin, Chief Security Officer

BSIMM 2011 Community Conference

Jim Hong, Kyle Randolph and I attended the BSIMM Community Conference last week at the Skamania Lodge in Stevenson, WA (about an hour outside Portland). The BSIMM (“Building Security In Maturity Model”) community is composed of folks who work on software security as part of their day job for organizations who have performed a BSIMM measurement. Adobe was one of the original nine organizations to kickstart BSIMM in the fall of 2008 and we conducted a second measurement in 2010. I’m also a member of the BSIMM Advisory Board. You can learn more about BSIMM at

Of the more than 40 organizations that have conducted a BSIMM measurement, 25 were represented by 77 attendees at last week’s BSIMM community event. This group made for a very interesting subset of the broader security community because everyone is focused narrowly on practical defensive software security. Typically, offensive security topics tend to dominate most of the security conferences I attend. Even the conference talks that are supposedly about defensive topics tend to be more focused on how to employ offensive techniques during testing rather than on providing a holistic view of real-world defensive software security. So, it is refreshing and exciting when someone tries to rally attention towards research into truly defensive techniques. (The Microsoft BlueHat Prize announced at BlackHat this past summer or the exchanges among the members of SAFECode are other examples that come to mind.)

I presented “Adobe Product Security Through the BSIMM Lens: 2008-2011″ on the first day of the BSIMM event and attended a number of interesting talks. However, the most valuable part of the event, as is always the case, was the “hallway track.” The chance to compare notes with peers from other organizations tackling the same technical problems with such widely varying resources, priorities and definitions of success was the reason I attended, and I wasn’t disappointed.

To sum it up, the BSIMM community event was a great opportunity to spend time with like-minded folks from across the industry.  I’m looking forward to next year.

Adobe Welcomes Siemens to SAFECode!

I’m excited to welcome Siemens as the newest member of SAFECode and Dr. Frances Paulisch to the SAFECode board of directors.

Adobe joined SAFECode (the Software Assurance Forum for Excellence in Code) in 2009. You can read a bit about what I was hoping Adobe would gain from its SAFECode membership in a Q&A posted at the time to the SAFECode blog. Since we joined, we’ve contributed to a couple of major publications—the Fundamental Practices for Secure Software Development paper and an Overview of Software Integrity Controls—as well as numerous smaller efforts.

However, the biggest value Adobe has gained from its SAFECode membership comes from the very frequent interactions we have at all levels with our peers from the secure software engineering teams of SAFECode member firms. From comparing external communication strategies to technical release checklists and tooling, the benefit of tapping into a community of people tackling the same challenges can not be overstated.

Expanding this community to include the Siemens security folks is a big win for the SAFECode community and will help accelerate the hard work Siemens is putting into securing their software. SAFECode is always on the lookout for prospective new members, so if you think your organization might be a fit, please get in touch. You can learn more about SAFECode here.

Notes from RSA Conference Europe 2011

Brad Arkin here, live from RSA Conference Europe 2011, which opened earlier today in London. I’m moderating a panel on Thursday, October 13, 2011, titled “Building Secure Software—Real World Software Development Programs” (ASEC-302). If you happen to be at the show, please drop by King’s Suite A (West Wing) at the Hilton London Metropole Hotel at 10 a.m. to join me and my SAFECode peers (Steve Lipner from Microsoft, Gunter Blitz from SAP, Reeny Sondhi from EMC, and Janne Uusilehto from Nokia) as we discuss our experiences of putting together secure development programs. Also, Bryan Sullivan is presenting “NoSQL, But Even Less Security: Attacking and Defending NoSQL Databases” (DAS-207) on Wednesday, October 12, 2011 at 2:10 p.m. (A podcast introducing Bryan’s talk is available here.)

Coinciding with the first day of the conference, Microsoft today released volume 11 of its Security Intelligence Report (SIR). One of the key take-aways is the importance for users to stay up-to-date. Microsoft’s findings show that less than one percent of exploits in the first half of 2011 were against zero-day vulnerabilities—or in other words: More than 99 percent of exploits in the first half of 2011 were targeting outdated installations, exploiting vulnerabilities for which a fix was already available. But don’t take my word for it; give the report a read. It provides valuable insight into global online threats, including zero-days, which help customers better prioritize defenses to more effectively manage risk.

How Did You Get to that Number?

There’s been some chatter about CVE numbers lately, so I thought it would be helpful to clarify Adobe’s position on how we use CVEs to communicate product security information. describes them as “international in scope and free for public use, CVE is a dictionary of publicly known information security vulnerabilities and exposures.”

Unfortunately, there are many differences in opinion on how CVEs should be used in real-world situations. If there are four instances of unsafe buffer usage resolved with a single buffer size check, does that represent four CVEs or just one? If vulnerable code is copied and pasted into multiple products, should the vulnerable line of code be described with a single CVE or one unique CVE for each product? How does the answer change, if the product is vulnerable because of linking a vulnerable library rather than copied-and-pasted code? The real-world questions go on and on….

In response to these ambiguities, software producers and the security community have done the best they can. CVE allocation tends to be fairly consistent within a product or organization over time, but there can be significant differences when you compare one vendor’s practices to another’s. This is one of the reasons why blind CVE counting to compare different products is usually a bad way to assess their relative security.

Here are some rules of the road Adobe follows when it comes to CVE allocation:

  • Any externally reported vulnerability gets assigned a CVE that is listed in the security bulletin. (In this age of fuzzers, it can be difficult to determine when a set of crasher input files triggers the same or different vulnerabilities. It’s not unusual for us to see a large number of crashers with different hashes get resolved by a single bug fix in the code.)
  • Any zero-day or in-the-wild exploit triggers a CVE assignment to describe the vulnerability targeted by the exploit.
  • Any bug identified by Adobe engineers and resolved as part of the Adobe Secure Product Lifecycle (SPLC) is not assigned a CVE. In looking at the CVE description, we do not consider these bugs “publicly known.” Following the same reasoning, any bug identified by consultants, contractors or partners as part of their joint engineering effort/work with Adobe is also not assigned a CVE.

These rules of the road are just a starting point. There are many examples of complicated real-world scenarios where we’ve had to make precedent-setting decisions. We always try to stay consistent with the guidance from Mitre and our own internal precedents. We also frequently compare notes with other software producers and our friends in the security community to collect ideas on how we can improve our internal approach. Since the whole point of using CVEs is to help facilitate communication about software vulnerabilities, our goal is to use CVEs in the same manner as other ISVs to avoid any potential confusion within the industry.

The Flash Player update released on August 9, 2011 presented us with a new situation. We issued a ‘critical’ security bulletin that described 13 CVEs reported to us by external sources. In the ‘Acknowledgments’ section, we also thanked Tavis Ormandy and the Google Chrome team for their great work in helping us harden this release of Flash Player. We didn’t allocate any CVEs because we viewed this testing as part of the SPLC that spans the joint engineering efforts with the Google Chrome team. This led to some confusion since the Google security team has a different approach to CVE allocation.

The initial run of the ongoing effort resulted in about 400 unique crash signatures, which were logged as 106 individual security bugs following the initial triage. As these bugs were resolved, many were identified as duplicates that weren’t caught during the initial triage. In the final analysis, the Flash Player update we shipped earlier this week contains about 80 code changes to fix these bugs.

So, what’s the right number of CVEs to allocate? In this particular case, some of the code changes we made were closely related within a single component, which would argue for consolidating them with a single CVE, while others were clearly distinct. At this point, we’d rather invest our time in continuing the hardening work that will make Flash Player more robust against attack than reviewing change logs. We’ve updated the security bulletin to include CVE-2011-2424 to describe this batch of bugs.

What’s most important is that industry partners like Google and Adobe are working together on projects like this to protect our mutual customers. Adobe greatly appreciates the assistance of the Google Chrome team on this and other projects that are part of our cooperation.

Brad Arkin
Senior Director of Product Security and Privacy

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

Background on APSA11-01 Patch Schedule

We just posted Security Advisory APSA11-01 announcing a critical vulnerability (CVE-2011-0609) in Adobe Flash Player, which also impacts the authplay.dll component shipping with Adobe Reader and Acrobat for Windows and Macintosh.

In the advisory, we referenced the following target ship schedule for the security updates addressing CVE-2011-0609 in Adobe Flash Player, Adobe Reader and Acrobat:

  • The security update for Adobe Flash Player 10.x and earlier versions for Windows, Macintosh, Linux, Solaris and Android is scheduled to be available during the week of March 21, 2011.
  • The security update for Adobe Acrobat X (10.0.1) and earlier 10.x and 9.x versions for Windows and Macintosh, and Adobe Reader 9.4.2 and earlier 9.x versions is also scheduled to be available by the week of March 21, 2011.
  • We currently plan to address CVE-2011-0609 in Adobe Reader X with the next quarterly security update for Adobe Reader, currently scheduled for June 14, 2011.

Let me provide some additional background on the decision not to update Adobe Reader X at this time. We evaluated a number of different options. In the end, we determined that the above patch schedule would allow us to provide the best balance of risk mitigation and admin/update costs for our customers. Here are some points we considered in developing this schedule:

  • Reports that we’ve received thus far indicate the attack is targeted at a very small number of organizations and limited in scope. The current attack leverages a malicious Flash (.swf) file inside a Microsoft Excel (.xls) file. The .xls file is used to set up machine memory to take advantage of a crash triggered by the corrupted .swf file. The final step of the attack is to install persistent malware on the victim’s machine.
  • We have not received reports or malicious samples of attacks leveraging this vulnerability via .pdf files. However, attackers have leveraged these type of Flash Player vulnerabilities in the past via .pdf files to attack the embedded authplay.dll component shipping with Adobe Reader and Acrobat v9. Out of a preponderance of caution we took the decision to ship out-of-cycle updates for Adobe Reader and Acrobat v9, and Acrobat X to mitigate the risk of attackers shifting the attack from an .xls container to a .pdf container.
  • Adobe Reader X Protected Mode (aka “sandboxing”) is designed to prevent the type of exploit we are currently seeing in the .swf/.xls attack from executing. Even if an attacker made the transition to a .pdf container for the exploit, the sandbox would prevent the final step of malicious software installation on the victim’s machine.
  • We considered providing an out-of-cycle update for Adobe Reader X as well, which would have delayed the current patch release schedule by about another week. However, given the mitigation provided by the Adobe Reader X sandbox and the absence of attacks via PDF, we determined that an out-of-cycle update would incur unnecessary churn and patch management overhead on our users not justified by the associated risk, in particular for customers with large managed environments.

We are working closely with our Microsoft Active Protections Partners (MAPP), customers and other partners in the security community to monitor the situation. Should we see different types of exploits targeting CVE-2011-0609 in Adobe Reader X, we will update our current plan accordingly.

Brad Arkin
Senior Director, Product Security and Privacy

Adobe Reader X is Here!

Since we first announced the development of a sandbox for Adobe Reader on July 20, 2010, there has been a tremendous level of interest in the sandboxing topic — and an equal level of anticipation for Adobe Reader X. Over the last few months, the Adobe Reader engineering team together with the Adobe Secure Software Engineering Team, partners in the software development community such as the Microsoft Office security team and the Chrome team at Google, as well as customers, third-party consultancies in the security community, and other external stakeholders were hard at work to help ensure the sandbox implementation was as robust as possible.

Today, all of the hard work has come to fruition, and we are happy to announce that Adobe Reader X (with Protected Mode, aka sandboxing, on Windows) is now available! To download the new version of Adobe Reader, visit

Adobe’s product security initiatives are focused on reducing both the frequency and the impact of security vulnerabilities. Adobe Reader Protected Mode represents an exciting new advancement in mitigating the impact of attempted attacks. While sandboxing is not a security silver bullet, it provides a strong additional level of defense against attacks. Even if exploitable security vulnerabilities are found by an attacker, Adobe Reader Protected Mode will help prevent the attacker from writing files or installing malware on potential victims’ computers.

For more information on Adobe Reader X and on Adobe Reader X Protected Mode in particular, see the following blog posts:

We are excited to present Adobe Reader X, and — as always — we welcome your feedback and comments!

Pssst! PDF is an ISO Standard

PDF is closely associated with products such as Adobe Reader and Acrobat, but the ubiquitous file format has been an open ISO Standard since 2008. Anyone can develop and distribute software to create and view PDF documents. This means that not all PDF-related vulnerabilities are automatically Adobe vulnerabilities.

Why point this out today, you may ask? There are a number of public discussions happening this week around the so-called “iPhone jailbreak PDF vulnerability,” and we have received a significant number of inquiries from concerned customers asking whether this vulnerability affects Adobe Reader or Acrobat. This vulnerability appears to be in the implementation of the PDF viewing technology — as opposed to a problem with the PDF specification itself.

As is the case with any report of vulnerabilities potentially affecting Adobe products, we have carefully investigated this particular exploit. An initial public report of the sample crashing Adobe Reader has since been retracted. All of our analysis to date indicates that the vulnerability used in the iPhone jailbreak does not impact Adobe Reader or Acrobat.

Working Together: Adobe Vulnerability Info Sharing via Microsoft Active Protections Program (MAPP)

Last week, we introduced Adobe Reader Protected Mode (aka sandboxing).  This security mitigation feature in the next major version of Adobe Reader is just the most recent public example of the proactive engineering steps we are taking to help protect our customers.  Despite our excitement about sandboxing, we remain realistic that offensive techniques are always marching forward.  A key priority for us is the ability to work with the broader security community to effectively respond to and mitigate new threats.

Today, I’m happy to announce a significant initiative in collaboration with Microsoft: Starting this fall, we will begin sharing vulnerability information for all Adobe products through the Microsoft Active Protections Program. Launched in October 2008 by the Microsoft Security Response Center, MAPP represents a global collaborative effort to facilitate advanced information sharing of Microsoft (and now Adobe) product vulnerabilities with security software providers, such as antivirus or intrusion detection and prevention vendors. By receiving vulnerability information prior to the public release of a security update, MAPP partners get an early start over exploit code writers, enabling them to offer protection to customers in a timely manner.

MAPP is a great example of a tried and proven model giving an upper hand to a network of global defenders who all rally behind a shared purpose—protecting our mutual customers.

We look forward to working with Microsoft and the 65 global MAPP partners. We are confident that by working together to defend customers and partners against those with malicious intent, we can make a positive impact on the security ecosystem.

Introducing Adobe Reader Protected Mode

In May 2009, I announced the major Adobe Reader and Acrobat security initiative that was already underway. The three main areas of focus of that initiative were code hardening, incident response process improvements, and a shift to a regular security update schedule. From our rapid incident response in urgent situations to the new Adobe Reader Updater, our investments in these areas are helping to keep our users safe.

As part of our commitment to product security, we are always investigating new technologies and approaches. Today, I’m very excited to share an example of a new mitigation technology and to start the public conversation around the next major step Adobe is taking to help protect users from attacks in a rapidly evolving threat landscape: Adobe Reader Protected Mode.

Scheduled for inclusion in the next major version release of Adobe Reader, Protected Mode is a sandboxing technology based on Microsoft’s Practical Windows Sandboxing technique. It is similar to the Google Chrome sandbox and Microsoft Office 2010 Protected Viewing Mode. Adobe has been working closely with David LeBlanc, Dan Jump and other members of the Microsoft Office security team, Nicolas Sylvain and the Chrome team at Google, as well as third-party consultancies and other external stakeholders to leverage their sandboxing knowledge and experience. We greatly appreciate the input and support from all of our partners and friends in the community who helped with this effort.

With Adobe Reader Protected Mode enabled (it will be by default), all operations required by Adobe Reader to display the PDF file to the user are run in a very restricted manner inside a confined environment, the “sandbox.” Should Adobe Reader need to perform an action that is not permitted in the sandboxed environment, such as writing to the user’s temporary folder or launching an attachment inside a PDF file using an external application (e.g. Microsoft Word), those requests are funneled through a “broker process,” which has a strict set of policies for what is allowed and disallowed to prevent access to dangerous functionality.

The initial release of Adobe Reader Protected Mode will be the first phase in the implementation of the sandboxing technology. This first release will sandbox all “write” calls on Windows 7, Windows Vista, Windows XP, Windows Server 2008, and Windows Server 2003. This will mitigate the risk of exploits seeking to install malware on the user’s computer or otherwise change the computer’s file system or registry. In future releases of Adobe Reader, we plan to extend the sandbox to include read-only activities to protect against attackers seeking to read sensitive information on the user’s computer.

Adobe Reader Protected Mode represents an exciting new advancement in attack mitigation. Even if an exploitable security vulnerability is found by an attacker, Adobe Reader Protected Mode will help prevent the attacker from writing files, changing registry keys or installing malware on potential victims’ computers.

This post is just the beginning of our public conversation around Adobe Reader Protected Mode. We look forward to continuing the conversation — in person at upcoming security conferences or via this blog. Watch for more details as work progresses.