Peleus here. I focus most of my energy working with the Flash Player and AIR teams. The first half of the year had been fairly uneventful for Flash Player with only a small number of responsibly disclosed vulnerabilities reported over the last few months. The break was welcome and allowed us to focus on the more strategic security tasks that we don’t always blog about, but are still important parts of the Adobe Secure Product Lifecycle.
Unfortunately, nothing lasts forever and the last few weeks have been very busy for the Adobe Secure Software Engineering Team. We had to snap back into action on July 10th to handle the first of two different externally reported vulnerabilities that we ended up patching in Flash Player on July 30th. First, Microsoft notified us of a flaw in their ATL library that had the potential to affect many of Adobe’s products. The entire ASSET team mobilized to quickly identify which of Adobe’s over 200 products might be vulnerable. Fortunately for us, the MSVR team at Microsoft was well organized. They were able to share info early on that helped to speed the triage effort inside Adobe. We were able to identify and fix two vulnerable products (Shockwave and Flash Player) and confirm that many other widely distributed products like Adobe Reader and Connect Pro were NOT vulnerable. We also provided continual feedback into the Microsoft process that they could then, in turn, share with other partners.
Once the triage process for the ATL vulnerability was well under way we received a sample of a new attack in the wild against the Flash Player library within Reader. Although there are reports Adobe had known about this bug for eight months, the reality is that the July 16th report to the Product Security Incident Response Team (PSIRT) was the first time Adobe evaluated the bug as a security issue. The 12/31/08 bug was not caught as a security bug, so our usual Incident Response process was never initiated.
Flash is at the core of many of Adobe’s flagship products and this simultaneous patch effort required coordination between Reader, Flash Player and the AIR development teams. This is no small task when you consider that we need to distribute reliable patches to over 90% of the Internet and support multiple versions of each product across multiple versions of the Windows, Macintosh and UNIX operating systems. Granted, we have been doing this for some time so we have automation in place to make the technical processes efficient and accurate. However, we still needed the Flash team to coordinate the creation of the patch and provide guidance to the Reader and AIR teams on adopting the solution. One mis-step in coordination could mean that the testing process starts all over again for each of the products resulting in a delay in the patch for our customers.
Since some of these products are among the most widely distributed software on Earth we used every available resource to get software updates out as soon as we could. We managed to execute a plan for updating Shockwave, Flash Player, AIR, Adobe Reader and Acrobat, all before the end of the month.
In addition to the tremendous amount of internal coordination required, PSIRT also managed the external aspects of the Adobe response. This included communicating with CERTs and other partners in the security ecosystem, creating CVE’s, issuing bulletins and advisories, and responding to customers and media inquiries. Each notification requires attention to detail so that we provide useful information, but not so much that we put more customers at risk. As with all major incidents, PSIRT is at the center of balancing the needs of Adobe’s customers, security researchers, product teams, partners and Adobe as a whole.
I recently read a ZDNet Zero Day blog by George Stathakopoulos talking about coordination within the security community and it’s a common theme in my conversations with friends in the security community. Our coordination with Microsoft on the ATL header vulnerability was definitely key to being ready in time for their release date. In addition, coordination within Adobe was critical to shipping four products within the same week, all while balancing the needs of both external and internal stakeholders. We hosted daily security meetings that leveraged Adobe Connect Pro as a 24/7 virtual war room where we could post the latest information, record IM conversations and track issues. We used Buzzword for collaborative authoring our PSIRT blog posts, Advisories, and Bulletins that are key to communicating our progress with customers and the security ecosystem. Overall, situations like these highlight the need for security professionals to truly be a community. With all the technological solutions and formal processes we have at our disposal for creating secure products, we sometimes forget how important the little things like communication are to security.
Peleus here. Within Adobe, we do all that we can to secure our products, however, we can’t do everything on our own. Cooperation with the security community is essential to ensuring secure deployment of our products by our customers. Over the last year, Adobe has taken several measures to better interact with the security ecosystem including assisting groups such as OWASP, sponsoring conferences such as ShmooCon and CanSecWest, and building relationships with vendors and consultants. Our recent work with vendors to supply solutions for deploying SWF content securely is one example of these projects.
Coming out of the consulting world, I understood the challenges in analyzing a web site based on the Flash Platform. Although there were some basic tools and a handful of people with the appropriate knowledge, it was clear that more could be done. To solve this multi-faceted issue Adobe would need the assistance of the security community. From our end, we have been increasing our security documentation for developers, such as our Creating more secure SWF applications article, however, documentation can only go so far. We also needed to build alliances with vendors in the industry to help deliver the tools necessary to analyze production code.
This week, HP has stepped up to assist Flash developers by providing a free static analysis tool called SWFScan. SWFScan is able to perform static analysis on SWF content to identify common coding errors that can lead to vulnerabilities once the SWF is deployed. This allows developers to identify vulnerabilities earlier in the development cycle. Consultants who do not have access to source code can also leverage SWFScan to perform offline analysis of content by using it to decompile SWFs. SWFScan will work with ActionScript 2.0 and ActionScript 3.0 code and is free for everyone to use.
Last month, IBM launched AppScan 7.8 which can dynamically evaluate SWF content and perform penetration testing on a web site. Their tool is targeted at enterprise customers and allows users to enumerate flaws during the quality assurance phase of development. While static analysis can find many flaws, it is also important to analyze a SWF within the full context of its deployment. AppScan can monitor the SWF as it executes to identify flaws within the SWF’s run-time interactions with existing content as well as server communications through protocols such as AMF.
Both tools fit together nicely by allowing for security analysis at both the implementation and quality assurance phases of development. With these tools from HP and IBM, in addition to the work that Adobe does to help secure Flash Player and improve security documentation, our customers now have a more complete solution for deploying SWF content securely.
Within ASSET, we always try to examine the security of our products from as holistic a view as possible. Therefore, Adobe will continue to work with these and other vendors in the security community to bring together solutions that will help customers safely deploy our products and allow end-users to safely interact with them.
Recently, when speaking with a few researchers about why they did not report vulnerabilities to Adobe, we have heard a few variations of, “I didn’t think Adobe would care.” Those responses were disappointing to the Adobe Secure Software Engineering Team (ASSET) and it was clear that Adobe needed to do more to reach out to security community and be transparent in our efforts to protect customers. ASSET strives to improve the Secure Development Lifecycle within Adobe for all products, coordinate the Adobe Product Security Incident Response Team (PSIRT) and perform security community outreach activities. Those comments indicated that Adobe needed to do more with regards to communicating the activities of ASSET to the external community. This blog is one of the methods we will use to achieve that goal.
Adobe has taken significant proactive measures to improve the security of our products over the last few years and we plan to continue to build upon that foundation moving forward. Through this blog we hope to communicate what we have achieved and where our customers can expect us to be in the future. We will be providing specific details on the current status of our individual security programs within Adobe in upcoming posts. However, to set the scene, let’s take a quick look back on the last year that led to where we are today.
First, it is very clear to Adobe that we are receiving increased attention from the security community. Adobe has been responding to this increased attention over the course of the last year by proactively investing in both internal and external security measures to further protect our customers. We have added several new people to our team including Brad Arkin who recently joined Adobe in the new role of Director of Product Security and Privacy within Adobe. For additional support internally, we have increased our efforts in disseminating security information, tools and resources to the individual product teams. One example of this effort includes our recent initiative to expand the library of online security training modules as part of a broader set of education programs for developers and quality engineering. For the external community, we have also contributed towards making more security information available to the customers who deploy our products in order to assist developers and administrators in implementing best practices with our software.
The current focus on Adobe products from the security community has also lead to an increased number of reported security issues. To that end, Adobe has become more aggressive in responding to external security incidents. One recent example was the clickjacking issue reported to us by Robert Hansen and Jeremiah Grossman. Adobe responded by implementing a cross-platform, cross-browser patch within weeks of notification. And while the complexities of the many environments our products run on can sometimes prevent us from responding as quickly to other reported issues, this specific example helped to raise the bar for what we can achieve and what we want to work towards in the future. For researchers who find issues with our products, you should know that Adobe follows industry standard responsible disclosure practices and we will give credit to all researchers who follow that process when reporting vulnerabilities.
These are just a few of the steps that Adobe and ASSET has taken to improve the security of our products and services. This blog will help describe in more detail how moving forward we plan to improve in each area of the security lifecycle. By publishing information on our security development lifecycle, we hope to convey to our customers Adobe’s efforts to ensure the security of their infrastructures. In addition, it is our hope that the information we provide about the lessons we’ve learned during these processes can help to further the industry. In short, we care.