Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.
What Adobe Has Done to Improve Security
Public perception dictates that Adobe products are unsecure by default. But based on the material I was offered to read through, Adobe has taken definite steps to improve not only product development but also how the company utilizes community engagement to build better, more secure applications.
Rod Trent
August 19, 2013
16 Min Read
In BYOD, Except if it's Android, I related the latest round of Android security woes to Adobe. Anyone that has worked in IT during the last 10 years knows that Adobe products (Acrobat Reader, Flash, etc.) have had some of the worst security records of any products. Strong security and Adobe were never used in the same sentence, if only as a joke.
In the Android article, I stated that "Android is the new Adobe," but after chatting over email with a senior manager of corporate communications with Adobe, I may have to revise that statement a bit. Not because they want me to, but because I was made aware of significant changes that Adobe has made, all based on their security record and public perception.
Now, public perception dictates that Adobe products are unsecure by default, but based on the material I was offered to read through, Adobe has taken definite steps to improve not only product development, but how the company utilizes community engagement to build better, more secure applications.
I truly appreciate Adobe taking the time to enlighten me on their new security focus. And, I'm sure you'll appreciate it, too, since the majority of what Adobe has done isn't public knowledge. We agreed that it's valuable for you all to know exactly what Adobe has done internally, to help fix public perception and get back to focusing on the true security offenders like Android.
As passed on to me, here's the details of what Adobe has accomplished to tighten security and provide a better operating landscape for users of their products:
Security Teams at Adobe
Adobe has a team in place (the Adobe Secure Software Engineering Team – ASSET), which is dedicated to ensuring our products are designed, engineered and validated using security best practices. A second team within ASSET (the Product Security Incident Response Team – PSIRT) is responsible for responding to and communicating about security issues. ASSET and PSIRT (as they exist today) were put in place during the integration of Macromedia and Adobe in late 2005 by combining the corresponding security teams from each company, and these teams continue to evolve to best address the threat landscape facing Adobe’s products.
All engineering teams at Adobe work very closely and proactively with the Adobe Secure Software Engineering Team (ASSET) during each phase of the Adobe Secure Product Lifecycle (SPLC). In addition, product teams have dedicated security development and testing groups in place. As a result of changes in the threat landscape, we have about seven times as many engineers dedicated to security today compared to 2009.
The Adobe Secure Product Lifecycle (SPLC)
ASSET owns the Adobe Secure Product Lifecycle (SPLC), which is the equivalent to Microsoft's Security Development Lifecycle (SDL). All code and features in Adobe products are subject to the SPLC. The SPLC integrates standard secure software activities such as threat modeling, automated and manual security code reviews, and fuzzing into the standard Adobe Product Lifecycle we follow for all projects. The graphic/screen shot below shows the different phases of the SPLC as well as key aspects of each phase.
The ASSET Certification Program
A program that was introduced by ASSET in February 2009 and which has become a critical part of the SPLC is the “ASSET Certification Program.” This is an internal program for Adobe engineering and product teams designed to raise security awareness and implement best practices prior to and during the planning and design phases of a product to ensure potential areas for vulnerabilities are identified and addressed early. A majority of Adobe’s product/engineering team members have gone through the program.
Product Security Incident Response
Adobe also has significant investment in our reactive capabilities in the event of a security incident. The Product Security Incident Response Team (PSIRT) coordinates with the security community (including vendors and researchers) as well as the internal engineering teams and communications teams to get relevant information such as threat mitigations out to users as soon as possible.
Product Security Initiatives
Over the last three years in particular, we have increased the investment in our security efforts with focused initiatives, faster response times, and improved communication to customers and stakeholders. This included improving the security of legacy sections of the code base by targeting high risk areas of the application for fuzzing, static code analysis, manual code review, threat modeling, and strengthening input validation. And we significantly improved incident response processes for regularly scheduled updates as well as for urgent situations, such as a zero-day.
We also made a number of significant security enhancements specifically to Adobe Reader and Acrobat:
With the Adobe Reader / Acrobat update in October 2009, we included security enhancements around Adobe Reader and Acrobat’s handling of JavaScript—at the time one of the main attack vectors for PDF/Adobe Reader. These include the ability to disable JavaScript using an improved “gold bar” user interface (improvement from previous pop-up box), significant improvements to strengthen input validation on all JavaScript calls, as well as the introduction of a JavaScript blacklisting mechanism.
With the April 13, 2010 Adobe Reader / Acrobat update, Adobe activated a new Adobe Reader Updater / Adobe Acrobat Updater. The new updater is designed to keep end-users up-to-date in a much more streamlined and automated way. It was introduced because the majority of attacks we are seeing are exploiting software installations that are not up-to-date with the latest security updates. With the activation of the new updater, Windows users have the option to download and install updates for Adobe Reader and Acrobat automatically, without user interaction. The following three update options are available to users:
Automatic: Updates are downloaded and installed automatically, without user interaction. Adobe recommends this option for most end-users. (Available for Windows users only.)
Semi-Automatic: Updates are downloaded automatically, but the user has to choose whether or not to install the update.
Manual: The user has to manually check for updates and kick off the installation. This option may appropriate in particular for administrators in businesses following patch cycles specific to their organization.
During the first phase of the roll-out of the new updater, Adobe utilized the user’s existing 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 the quarterly update delivered on June 14, 2011, we entered the next stage 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 was presented with a screen for the automatic update option for the first time when the Adobe Reader Updater detected for the availability of the September 13, 2011 update.
On November 18, 2010, Adobe announced the availability of Adobe Reader X with Protected Mode (aka sandboxing) under Windows. Adobe Reader Protected Mode represented an exciting new advancement in mitigating the impact of attempted 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.Note that since we added sandbox protection to Adobe Reader in November 2010, the exploit announced in our February 13, 2013 security advisory is the very first exploit in the wild that break out of the Adobe Reader Protected Mode sandbox.
With the Adobe Reader / Acrobat update on June 14, 2011, Adobe introduced Adobe Acrobat X (10.1) Protected View (aka sandboxing). This security enhancement for Adobe Acrobat extends the concept of Adobe Reader Protected to the Acrobat browser plugin; it also introduces Adobe Acrobat Protect View for document viewing with Acrobat in standalone mode. 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.
On January 10, 2012, Adobe added a new JavaScript whitelisting capability in Adobe Reader and Acrobat X (10.1.2) and 9.5, allowing JavaScript execution in PDF files based on document trust. If a document is trusted, JavaScript execution will be allowed; but if it is untrusted, Adobe Reader and Acrobat will prevent all JavaScript execution.
With the Adobe Reader / Acrobat update on April 10, 2012, Adobe announced the following changes:o Rendering Flash (SWF) Content in Adobe Reader and Acrobat 9.5.1: We added an Application Programming Interface (API) to both Adobe Reader/Acrobat 9.5.1 and Flash Player to allow Adobe Reader/Acrobat 9.5.1 to communicate directly with a Netscape Plugin Application Programming Interface (NPAPI) version of Flash Player installed on the user’s system. Starting with the release of Adobe Reader 9.5.1 and Acrobat 9.5.1, Adobe Reader and Acrobat 9.x on Windows and Macintosh will use the Adobe Flash Player plugin version installed on the user's system (rather than the Authplay component that ships with Adobe Reader and Acrobat) to render any Flash (SWF) content contained in PDF files. From a security perspective, this means that Adobe Reader/Acrobat 9.x users will no longer have to update Adobe Reader/Acrobat each time we make available an update for Flash Player. This will be particularly beneficial to customers in managed environments because fewer updates help reduce the overhead for IT administration.o Rendering 3D Content in PDF FilesWith the Adobe Reader and Acrobat 9.5.1 updates, 3D content is turned off by default, since the majority of consumers do not typically open PDF files that include 3D content. 3D content in untrusted documents can pose a security risk, so we disabled the option by default to cut down on potential risk for users of Adobe Reader and Acrobat 9.x.o Further Alignment of the Adobe Reader/Acrobat Update Cycle with Microsoft’s ModelAfter three years of shipping a security update once a quarter and announcing the date of the next update the same day we ship the current update, we are making a change. We are shifting to a model that more closely aligns with the "Microsoft Patch Tuesday" cadence. Since we introduced the quarterly update cycle in 2009, we have come a long way in putting mitigations into place that make Adobe Reader and Acrobat a less attractive attack target. Sandboxing Adobe Reader and Acrobat X, in particular, has led to greater than expected results. Attackers have indicated through their target selection thus far that the extra effort required to attack version X is no longer worth it. Additionally, we have seen a lower volume of vulnerability reports against Adobe Reader and Adobe Acrobat. Given the shift in the threat landscape and the lower volume of vulnerability reports, we feel that a strict quarterly release cycle is no longer warranted.
Most recently (in October 2012), Adobe introduced a number of new or improved security capabilities with Adobe Reader and Acrobat XI:o Adobe Reader XI Protected Mode (Enhanced)In our Adobe Reader X sandbox implementation, the sandboxing architecture’s primary focus was on “write protection” to prevent the attacker from installing malware on the user’s machine and from monitoring the user’s keystrokes when the user interacts with another program. In Adobe Reader XI, we added data theft prevention capabilities by extending the sandbox to restrict read-only activities to help protect against attackers seeking to read sensitive information on the user’s computer.o Adobe Reader Protected View (New) and Adobe Acrobat Protected View (Enhanced)To provide an additional layer of defense and strengthen the sandbox protection in Adobe Reader and Acrobat even further, we implemented a separate desktop and WinStation in Adobe Reader and Acrobat XI, which will block, for instance, screen scraping attacks. This mode effectively introduces a new Protected View in Adobe Reader and enhances the Protected View implementation in Adobe Acrobat even further. Protected View behaves identically for Adobe Reader and Acrobat, whether viewing PDF files in the standalone product or in the browser.o Force ASLR Support in Adobe Reader/Acrobat XIAdobe Reader and Acrobat leverage platform mitigations such as Data Execution Prevention (DEP), Address Space Layout Randomization (ASLR), etc. In Adobe Reader and Acrobat XI, we enabled support for Force ASLR on Windows 7 and Windows 8. Force ASLR improves the effectiveness of existing ASLR implementations by ensuring that all DLLs loaded by Adobe Reader or Acrobat XI, including legacy DLLs without ASLR enabled, are randomized. By enabling Force ASLR in Adobe Reader and Acrobat XI, we are making it even more difficult for an attacker to exploit vulnerabilities.o PDF Whitelisting FrameworkFor high-assurance, managed enterprise environments, we’ve added the Adobe PDF Whitelisting Framework, which allows administrators to selectively enable advanced functionality, such as JavaScript for specific PDF files, sites or hosts, on both Windows and Mac OS.
On the Flash Player side, note the following significant security (and privacy) enhancements made over the last two years:
On December 1, 2010, Adobe and Google announced the development of a sandbox for Flash Player within the Google Chrome browser. This first iteration of Chrome’s Flash Player sandbox for all Windows platforms introduced a modified version of Chrome’s existing sandbox technology that protects certain sensitive resources from being accessed by malicious code, while allowing applications to use less sensitive ones. This implementation represented a significant step in further reducing the potential attack surface of the browser and protecting users against common malware.
With the launch of Flash Player 10.3 on May 12, 2011, Adobe introduced a number of important security and privacy features: Flash Player 10.3 included a new auto-update notification mechanism for the Macintosh platform. With this new feature, Macintosh users started receiving Flash Player update notifications when new updates became available. (Note that this functionality was already previously in place for Windows users.) On the privacy side, Adobe worked closely with representatives from several key companies/open-source browsers—including Google and Mozilla—to define a new browser API (NPAPI ClearSiteData) for clearing local data. Any browser that implements the new API is able to clear local storage for any plugin that also implements the API. Flash Player was the first plugin to support the new API, providing users with a simpler way to clear local storage from the browser settings interface, similar to how they clear their browser cookies. In addition to coordinating with the open-source browsers, Adobe also teamed up with Microsoft to provide equivalent functionality within Internet Explorer. With the launch of Flash Player 10.3, users were able to take advantage of this functionality in Internet Explorer 8 and 9. And last but not least, Flash Player 10.3 introduced a redesigned Flash Player Settings Manager to make it easier for users to manage their Flash Player settings, which allowed Windows, Mac and Linux users to access the Flash Player Settings Manager directly from the Control Panel or System Preferences on their computers.
On September 21, 2011, Adobe introduced several security enhancements for Flash Player, including the addition of support for SSL socket connections, which will make it easier for developers to protect the data they stream over the Flash Player raw socket connections, and a secure random number generator.
On February 6, 2012, Adobe launched a public beta of Flash Player with sandboxing (aka “Protected Mode”) for the Firefox browser. Adobe Flash Player Protected Mode for Firefox 4.0 or later was made available in Flash Player 11.3 on June 8, 2012. It is supported on both Windows Vista and Windows 7.
With the release of Flash Player 11.2 on March 28, 2012, Adobe introduced a new background update mechanism for Windows users, designed to keep end-users up-to-date in a much more streamlined and automated way. Windows users have the option to download and install updates for Adobe Flash Player automatically, without user interaction. After a successful installation of Adobe Flash Player 11.2, users were presented with a dialog box to choose an update method. The following three update options are available to users:
Allow Adobe to install updates (recommended)
Notify me to install updates
Never check for updates (not recommended)
Additionally, the user can change the update preferences at any time via the Flash Player Settings Manager, which for Windows users can be accessed via the Control Panel. The new Adobe Flash Player background updater updates all instances of a release version of Adobe Flash Player for all Web browsers on a computer. Previously, users had to perform separate updates for each Web browser running on their system.
A Mac version of the Flash Player background updater was delivered with the Flash Player 11.3 release on June 8, 2012.
Community Engagement
In addition to working very closely with the security research community, ASSET/PSIRT have great working relationships with counterparts in other organizations—such as Microsoft, Symantec and McAfee—which we leverage for the exchange of technical and process information as well as telemetry regarding attack data and techniques.
As part of our collaboration with Microsoft, we announced on July 28, 2010 that Microsoft would extend its Microsoft Active Protections Program (MAPP) to include vulnerability information sharing from Adobe. See http://blogs.adobe.com/asset/2010/07/working-together.html for additional information on this announcement.
In another example, Adobe has been working closely with Microsoft to help improve the software update experience for our mutual customers. In 2011, we introduced support for Microsoft System Center Updates Publisher (SCUP) in Adobe Reader X and Adobe Flash Player, making it easier for Microsoft System Center Configuration Manager (SCCM) and Microsoft System Center Essentials (SCE) customers to import Adobe updates through the Microsoft System Center Updates Publisher (SCUP) and manage their distribution to client computers. In October 2012, Flash Player started shipping with Internet Explorer 10 on Windows 8. Flash Player installed with Internet Explorer 10 on Windows 8 is now being updated via the Microsoft Windows Update mechanism customers are familiar with.
In September 2009, Adobe joined SAFECode (Software Assurance Forum for Excellence in Code), a non-profit organization focused on the advancement of effective software assurance methods. As a SAFECode member, Adobe is actively involved in partnering with other SAFECode members to share lessons that we’ve learned with the software industry. Brad Arkin (senior director, security, Adobe products and services) is a member of the SAFECode board.
Adobe is also one of the original participants of the “Building Security In Maturity Model” (BSIMM) study and a member of the BSIMM Advisory Board. BSIMM was first launched in March 2009, and is the industry’s first and only structured set of best practices for software security based on real-world data. The BSIMM project is led by Fortify Software and Cigital, and is designed to help software vendors determine where they stand with their software security initiative and how to evolve their efforts over time. The original nine companies contributing to the BSIMM were Adobe, The Depository Trust & Clearing Corporation (DTCC), EMC, Google, Microsoft, QUALCOMM, Wells Fargo and two un-named financial institutions.
And last but not least, the Adobe Product Security Incident Response Team (PSIRT) is a member of the Forum of Incident Response and Security Teams (FIRST). FIRST brings together a wide variety of security and incident response teams, including product security teams from the government, commercial, and academic sectors.
Brad Arkin is also a member of the BSIMM (Building Security In Maturity Model) advisory board, the SAP Security Advisory Board, and the customer advisory boards for security consultancy iSec Partners and security tools vendor Veracode.
Adobe Security Resources
Adobe Security Portal: http://adobe.com/security
Adobe Secure Software Engineering Team (ASSET) Blog: http://blogs.adobe.com/asset
Adobe Product Security Incident Response Team (PSIRT) Blog: http://blogs.adobe.com/psirt
Adobe Security on Twitter: @AdobeSecurity
Brad Arkin on Twitter: @BradArkin
Read more about:
AdobeAbout the Author
You May Also Like
.jpg?width=700&auto=webp&quality=80&disable=upscale)
