I’m excited to welcome Steve Adegbite to the Adobe Secure Software Engineering Team (ASSET). Steve is a familiar face to anyone who has spent some time on the security circuit. From his early career as a U.S. marine and working for several three-letter federal agencies to the work he did in his previous job as a member of the Microsoft Security Response Center (MSRC) where he launched the Microsoft Active Protection Program (MAPP) and Defensive Information Sharing Program (DISP) initiatives, Steve has managed to keep himself at the front of the fast-changing security industry.
At Adobe, Steve is taking on the role of senior security strategist, reporting directly to me. In this role Steve will focus on coordinating our relationships with customers, partners in the security community and other external stakeholders. His top priority will be to continue and expand the two-way communication between Adobe and the security community. We deeply value the feedback we get from the security community on a daily basis, and I can’t wait for Steve to tap into his network on behalf of Adobe. In addition to his responsibilities at Adobe, Steve will continue serving as chairman of FIRST.
You can find Steve on Twitter @steveadegbite. (I’m still @bradarkin.)
Welcome to the team, Steve!
Senior Director, Product Security and Privacy
As part of the June 29, 2010 quarterly update for Adobe Reader and Acrobat, Adobe made changes to address a PDF “/launch” functionality social engineering attack demonstrated by security researcher Didier Stevens. This particular attack was not the result of exploiting a code vulnerability but instead relied on functionality defined in the PDF specification, which is an ISO standard (ISO PDF 32000-1:2008; section 184.108.40.206 of the specification defines the /launch command).
Since Didier Stevens’ initial post, we evaluated the best long-term approach for this functionality in Adobe Reader and Adobe Acrobat. The objective has been to allow end-users and administrators to better manage and configure features like this one to mitigate potential associated risks—while ensuring the impact on existing workflows customers rely on are minimized.
We determined that disabling the ability to open non-PDF file attachments with external applications by default would negatively impact a significant part of our customer base by breaking existing workflows. As an alternative, we added attachment blacklist functionality to block attempts to launch executables or other harmful objects by default.
When the user attempts to open an executable or other blacklisted file type, the following error message appears:
This capability can be re-enabled, i.e. for organizations that rely on this capability.
While blacklist capabilities alone are not a perfect solution to defend against those with malicious intent (as highlighted by Le Manh Tung in a recent blog post), this option reduces the risk of attack, while minimizing the impact on customers relying on workflows that depend on the launch functionality. We will evaluate this workaround to determine whether additional changes to the blacklist are required.
As part of our defense in depth approach, we also altered the way the warning dialog (requesting user permission to launch non-PDF file attachments with external applications) works, further reducing the risk of the social engineering attack demonstrated by Didier Stevens. Previously, an attacker could have inserted instructions to the user into the warning dialog box. The release of Adobe Reader and Acrobat 9.3.3 and 8.2.3 addresses this dialog box manipulation technique. An example of the new dialog box is shown below:
In the event of an attacker working around the blacklist functionality and attempting the execution of a malicious executable or other harmful object, the attachment will not execute without first displaying the warning message requesting user permission to launch the attachment. The warning message provided includes strong wording advising users to only open and execute the file if it comes from a trusted source.
Administrators can also edit the default attachment blacklist in Adobe Reader and Acrobat 9.3.3 and 8.2.3 via the registry setting on Windows. For further information on editing the attachment blacklist, visit http://learn.adobe.com/wiki/download/attachments/64389123/Acrobat_Attachments.pdf?version=1.
This evening, we updated APSA10-01 for CVE-2010-1297 to include the target ship schedules for the security updates for Adobe Flash Player, Adobe Reader and Acrobat. The security update for Flash Player will be available by June 10, 2010. The security update for Adobe Reader and Acrobat will be available by June 29, 2010.
The June 29, 2010 security update for Adobe Reader and Acrobat represents an accelerated release of the next quarterly security update originally scheduled for July 13, 2010. In addition to addressing CVE-2010-1297, the accelerated next quarterly Adobe Reader and Acrobat update will also resolve a number of responsibly disclosed vulnerabilities. The full details will be in the Security Bulletin and Release Notes we will publish when the security update is posted.
Among other options, we also considered the alternative of releasing a one-off 0-day fix followed a couple of weeks later by the July 13 quarterly update. However, two patches within three weeks would have incurred too much churn and patch management overhead on our users, in particular for customers with large managed environments.
In April, I wrote about some changes we were making to provide the latest version of Adobe Reader for the most popular language/platform pairs offered on the Adobe Download Center. Given the accelerated release of the next quarterly update, we are working to also pull in the schedule for posting the new installers. However, we do not yet have a confirmed date to announce. Until the new installers are published, users who are downloading Adobe Reader for the first time from the Adobe Download Center can continue to update their installation via the new Adobe Reader Updater by selecting > Help > Check for Updates from the Adobe Reader toolbar.
Watch for additional information as these security updates become available. We will continue to provide updates via the Security Advisory section of the Adobe website as well as the Adobe PSIRT blog.
One of the common themes I promote when speaking publicly about software security is the importance of staying up-to-date. Most users who ever encountered a security problem using Adobe products were attacked via a known vulnerability that was patched in more recent versions of the software. This is why we’ve invested so much in the new Adobe Reader Updater that goes into full production with our Tuesday April 13, 2010 release. (For more details on the new updater, see Steve Gottwals’ Adobe Reader blog post titled “Upcoming Adobe Reader and Acrobat 9.3.2 and 8.2.2 to be Delivered by New Updater.”)
We’re also hard at work on ways to better protect our enterprise users in managed desktop environments by collaborating closely with Microsoft to make 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. We’ll have more details to share later in the year as work progresses.
Given this emphasis on staying up-to-date, we have been fielding questions about why the Adobe Download Center at http://get.adobe.com/reader/ doesn’t always serve the most recent version of Adobe Reader. (For instance, when the April 13, 2010 update goes out, the latest version of Adobe Reader will be 9.3.2, while the Download Center will offer version 9.3.0.) Since the explanation does not fit into the 140 characters of a tweet, let me provide more insight into the reasoning here:
Historically, the decision was based on resource allocation trade-offs and windows of risk. The Adobe Reader Download Center landing page offers more than 70 different full installers representing each supported language and platform pair. Each must be fully tested, and then the Download Center itself must be tested to make sure the correct language/operating system installer is offered to the various browser/language/operating system requests to the site. Despite all of the automation in place, this total effort still represents thousands of person-hours. For a “double-dot” release like 9.3.2, we only produce an update, which does not involve creating and testing full installers. This allows us to get the update out the door as soon as it is available.
The intended behavior of the update mechanism in the product is that it will check for updates the first time Adobe Reader executes after an installation. When everything works as intended, users get updated to the latest version the first time they run the product.
With all of that said, our commitment to protect our users is a key priority for us, and our continued efforts to help close the window of exposure to vulnerabilities is part of that commitment. As I mentioned earlier, the majority of attacks we are seeing are exploiting software installations that are not up-to-date with the latest security updates, which suggests that far too many users are currently not installing the security updates that would protect them. The new updater technology was designed to address part of this problem.
In addition, we are working on making a change to some of the language/operating system versions of Adobe Reader hosted on the Download Center. Starting with the next quarterly security update for Adobe Reader, currently scheduled for July 13, 2010, we will update the Download Center to offer an installer for the latest version of Adobe Reader for the English, German, Spanish, Japanese and French language versions for Windows, and the English version for the Mac. Today, these platform/language pairs represent the overwhelming majority of Adobe Reader downloads. With this change to the Adobe Reader Download Center, we believe we can help even more users get to the latest, most secure release and continue to drive the message of how important it is to stay updated.
We are constantly engaged in security process improvement efforts in order to strengthen the protection for our customers. This includes methods of reducing the window of exposure to vulnerabilities to make sure end-users are rapidly protected against quickly evolving threats as well as stronger controls within the product itself. Therefore, we always follow a strategy to protect the greatest number of end-users as expediently as possible. As we continue to make improvements to the security posture of our products, we’ll continue to communicate dates and details via the ASSET blog.
I sat down for a live chat session moderated by Dennis Fisher from Threatpost on Wednesday, February 24, 2010. I was impressed with the turnout and the number of great questions. Thanks again to everyone who participated. The transcript from the live session is here. I didn’t have time to get to all the questions I wanted to answer, so I’ve posted some of the overflow Q&A here:
Q: Has there been any consideration given to releasing a “light” version of Reader supporting a reduced feature set with a formally specified subset of the PDF ISO spec?
A: Adobe is exploring some ideas, but we are not currently actively working on a “light” version of Adobe Reader. Adobe continues to drive innovation in PDF products and services through active involvement in the ISO 32000 working group and through products like Adobe LiveCycle, Adobe Reader and Acrobat.
Q: Having msi installation packages for Flash and Shockwave is great, why not for Reader? It would make it easier to deploy updated versions.
A: We do offer “msi” installation packages of our full installers. When we deliver patches, those come in “msp” format.
Q: If you are willing to work with partners for distribution of patches, how about Microsoft and WSUS? Do you have a way of pushing updates from a local server within the organization instead of all workstations needing to connect to Adobe, like Microsoft WSUS server?
A: Today, enterprise customers typically disable the update mechanism built into the product and use their own enterprise tools for deploying our updates (which we make available to them from the support download section of our Web site). Microsoft and Adobe are working closely together to help improve the software update experience for our mutual customers. Through this collaboration we hope to make 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. When we have final details on this process, we will share them with our customers and the media, but for now, we have nothing to announce.
Updated response with more detail – March 17, 2010
Q: What are Adobe’s plans to make people feel more comfortable with their products–it seems to me that there is a perception (whether it’s true or not) that Adobe has not been on the ball with their updates.
A: We hope that through our increased efforts at transparency into our software security efforts we can help people outside Adobe understand our dedication to making our products as safe and secure as possible to use. After retooling our response processes in early 2009 we were able to respond within two weeks for four urgent incidents later in 2009. Our shift to quarterly security updates for Adobe Reader and Acrobat also gives our customers a predictable and regular security patch schedule for mitigating responsibly disclosed incidents.
Q: How often are your internal reviews and the consultants you hire finding new flaws, relative to the ones that we see reported elsewhere?
A:Our internal security processes, including the use of external consultants, are focused on preventing vulnerabilities in the end software that we ship to customers. We’ve found the most effective way for us to do this is by front-loading our efforts on early-phase security reviews and activities such as threat modeling, specification/design reviews, and other activities from our SPLC. The output from these activities are helping us to make sure that every release raises the bar for security.
Q: The Security Bulletin “Security update available for Adobe Download Manager” contains incorrect information on removing a Service in Windows. There is no way that a Service can be deleted from the Services Console in Windows. One must edit the registry’s CurrentControlSet to remove a Service.
A: Thank you for pointing out this error. We have updated the Security Bulletin text, and apologize for any confusion.
Q: Any chance that Adobe will ever make their products updatable by non-admin users on the Windows side? Deploying a new Adobe MSI every week is getting pretty old.
A: Adobe Flash Player requires admin privileges to install at this time due to the current installation location and need to update certain keys in the registry. We have been installing this way for years, but we welcome feedback and votes for this feature request. For Reader, the user has to be Admin for Windows Installer Service to install full installers (MSIs). On Vista and W7 it is possible that Windows Installer Service will allow to apply Patches (MSPs) without elevation under several conditions. Our new Reader/Acrobat updater will allow users to install without being Admin on Vista or Windows 7 systems.
A running theme on this blog is that ASSET and Adobe care a great deal about keeping our products secure and our customers safe. On Tuesday Adobe announced a corporate network security issue and since then we’ve seen media coverage and headlines indicating that vulnerabilities in Adobe Reader may have been the attack vector in this incident.
Just like we always do in the case of reports of security vulnerabilities in an Adobe product, we have been actively tracking down samples or other information regarding potential vulnerabilities in Adobe products related to this incident. The most definitive public description of the incident that we’ve seen thus far is the McAfee post here.
Similar to the McAfee researchers, we have not been able to obtain any evidence to indicate that Adobe Reader or other Adobe technologies were used as the attack vector in this incident. As far as we are aware there are no publicly known vulnerabilities in the latest versions (9.3 and 8.2) of Adobe Reader and Acrobat that we shipped on January 12, 2010.
This is a complex incident, the investigation is ongoing, and we will continue to work our partners in the security community and the other firms affected. We will continue to use the Adobe PSIRT blog as the first line of communication to our customer base regarding any product security vulnerabilities. Even though we don’t have any information regarding a zero day vulnerability in an Adobe product the sophistication of this incident also serves as a reminder to all of us the importance of layers of security to provide the best possible defense against those with malicious intent.
Since the vast majority of successful attacks against all software products are using known, already-patched vulnerabilities we strongly encourage all of our users to update to the latest version of Adobe Reader and Acrobat by visiting get.adobe.com/reader or selecting “Check for updates” from the Help menu.
We posted an update to Security Advisory APSA09-07 that reflects the target ship date of January 12, 2010 for the update to remediate vulnerability CVE-2009-4324. I thought folks might be interested in some of the analysis that went into developing the schedule for the fix, so let me share some of the details in this post.
We evaluated two different options for patching this vulnerability:
- Stop everything else and start work immediately on an out-of-cycle security update to resolve this vulnerability with a one-off fix. We made major investments as part of our security initiative earlier this year that allow us to deliver patches more quickly. We estimated that delivering an out-of-cycle update would require somewhere between two and three weeks. Unfortunately, this option would also negatively impact the timing of the next quarterly security update for Adobe Reader and Acrobat scheduled for January 12, 2010.
- Roll the fix for vulnerability CVE-2009-4324 into the code branch for the scheduled January 12, 2010 release. The team determined that by putting additional resources over the holidays towards the engineering and testing work required to ship a high confidence fix for this issue with low risk of introducing any new problems, they could deliver the fix as part of the quarterly update on January 12, 2010.
Two important considerations that contributed to our decision to select the second option:
- Customer schedules – The next quarterly security update for Adobe Reader and Acrobat, scheduled for release on January 12, 2010, will address a number of security vulnerabilities that were responsibly disclosed to Adobe. We are eager to get fixes for these issues out to our users on schedule. Many organizations are in the process of preparing for the January 12, 2010 update. The delay an out-of-cycle security update would force on the regularly scheduled quarterly release represents a significant negative. Additionally, an informal poll we conducted indicated that most of the organizations we talked with were in favor of the second option to better align with their schedules.
This is just a brief description of some of the points we considered in our analysis. Ultimately, the decision came down to what we could do to best mitigate threats to our customers, a critical priority to everyone at Adobe – and one we take very seriously.
Brad Arkin here. In my role as the Director of Product Security and Privacy I’m responsible for the security of all Adobe products and services. In practice this means that I manage both the proactive work the Adobe Secure Software Engineering Team (ASSET) does as well as the reactive Product Security Incident Response Team (PSIRT) activities.
Back in December, Peleus Uhley kicked off this blog with the post, “We Care.” In that first post, he discussed how Adobe’s commitment to the security of our customers shows up in our process, our schedules, resourcing, and more. Since then we’ve talked publicly about Adobe’s overall approach to software security, our incident response process, and our support for more security tools for Adobe technologies. Today’s post shares some details about the software security activities underway with two of our best known and widely used products, Adobe Reader and Acrobat.
The recent JBIG2 vulnerability (CVE-2009-0658), the associated exploits, and Adobe’s response (APSB09-04) were the subject of much discussion in the security community in February and March. The JBIG2 issue also sparked a lot of conversation internally at Adobe from executives to testers and developers. What started out as a routine incident response expanded to a broader effort by Adobe Reader and Acrobat engineers, culminating in permanent changes to our software security approach for those products.
Since February, Adobe Reader and Acrobat engineers have been executing a major project focused on software security. Everything from our security team’s communications during an incident to our security update process to the code itself has been carefully reviewed. Security is an ongoing process, so while we believe our plan will eliminate or mitigate many potential security risks, we are also working to enhance our ability to respond to externally found vulnerabilities in Adobe Reader and Acrobat in the future.
In particular, we have focused this security effort in three major areas:
- Code Hardening – For the past several years all new code and features for Adobe Reader and Acrobat have been subject to our modern Secure Product Lifecycle (SPLC). The Adobe SPLC is similar to Microsoft’s Security Development Lifecycle (SDL). The Adobe 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 SPLC activities have been successful in mitigating threats in new code development, but did not fully address problems in the existing code base. Therefore, an initiative in the current security effort has been focused on hardening at-risk areas of the legacy code. We’ve applied the latest SPLC techniques against these prioritized sections of each application. Even in cases where no immediate vulnerability was identified, we have been strengthening input validation on a best-practice basis. (Experience shows such validation is a powerful tool in preventing as-yet unidentified security holes.)
- Incident Response Process Improvements - We’ve targeted several specific areas where we are improving our incident response process. We expect folks outside Adobe will see more timely communications regarding incidents, quicker turn-around times on patch releases, and simultaneous patches for more affected versions as we move forward.
This approach was tested sooner than we would have liked with CVE-2009-1492/1493. Although this incident fell in the middle of our security effort, we were encouraged by the progress our response demonstrated. We worked to communicate early and often via our PSIRT blog and two weeks later, on May 12, 2009, we simultaneously shipped 29 binaries to update 17 different versions of Adobe Reader and Acrobat covering 32 languages for the Windows, Mac, and UNIX platforms.
- Regular Security Updates – Starting this summer with the initial output of our security code hardening effort, we plan to release security updates for all major supported versions and platforms of Adobe Reader and Acrobat on a quarterly basis. Based on feedback from our customers, who have processes and resources geared toward Microsoft’s “Patch Tuesday” security updates, we will make Adobe’s quarterly patches available on the same days. (Although our March 10, 2009 and May 12, 2009 security patches landed on Patch Tuesday, the timing was coincidental. In both cases, we shipped the patches as soon as we finished testing them.)
Software security is a rapidly evolving field and we are always on the lookout for ways to best adapt to the changing threat landscape. In developing this new approach to product security for Adobe Reader and Acrobat we’ve leveraged lessons learned by our friends and partners in the community. We look forward to continuing the conversation in person at some upcoming security conferences.
Watch this blog for more details as work progresses.