Archive for July, 2010

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.

A Perfect Match (Ready for New and Exciting Challenges)

A lot of my friends in the industry are curious why I chose Adobe among the opportunities I was considering when I decided I was due for a change. My new team at Adobe suggested this was a great topic to kick off my first ASSET blog post. So here goes…

The first thing to understand about me is that I love engaging with people to help solve security issues from both technical and people/process angles.   I believe that the technical aspect of a security issue is only a small part of a broader people and process problem.   This is what makes the community engagement side of my security work so intriguing.

It also allows me to strategically think about the best way to help influence and solve the immediate tactical problem (the technical part) by addressing the strategic long term issues in the people and process realm. Another reason why I was drawn to security is that it’s never short on challenges to keep you on your toes. Fresh challenges definitely keep things exciting.

Enter Adobe.  Adobe’s present position with regards to security is really unique and definitely challenging (multiple platforms, broad feature profiles, incredible reach, etc).  So as I learned more about Adobe I was drawn to the following things about the company:

  • A budding security culture that’s already started to get woven into the company’s DNA.
  • Smart technologists with a passion for doing the right thing for customers, particularly around security.
  • A company whose technologies have a long reach on multiple platforms. (Which means more toys for me to play with!)
  • A central product security team full of dedicated security professionals.
  • A place where I can engage every conceivable external audience on the topic of product security.
  • Not least, I finally found some sunshine! (Anyone that has lived in Seattle for sometime will appreciate this last one.)

With all of this I saw the opportunity to help make an impact on the security landscape. I was sold on joining the Adobe team.  Adobe is the right fit for my interest, talents and passions.  Look to hear a lot from me via the ASSET blog, Twitter and in person on what we (Adobe) are doing around product security.

It’s going to be a great ride.


A Big Welcome to Steve Adegbite!

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!

Brad Arkin
Senior Director, Product Security and Privacy

Update on Functionality Changes in Adobe Reader/Acrobat 9.3.3 in Response to PDF “/Launch” Social Engineering Attack

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 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