Interview with Peleus Uhley by David Sopas
David Sopas: To start this interview, how about telling our readers what's your background on security?
Peleus Uhley: I have spent my entire career in the security industry, starting as a developer for Anonymizer. In my current role, I am the Platform Security Strategist on the Adobe Secure Software Engineering Team (ASSET), which is responsible for ensuring Adobe's products are designed, engineered and validated using security best practices. My primary area of focus is Adobe platform technologies, including Adobe Flash Player and Adobe AIR. Before joining Adobe in 2007, I worked as a security consultant for companies such as Symantec and @stake.
DS: What's your opinion on the overall state of web application security in the world? PU: I’d say overall it is improving. The renewed competition in the browser market is driving innovation in security. I remember in the first half of this last decade, when the only major advancement in Web protocols was Microsoft’s addition of the HTTPOnly flag, and browser security was mainly focused on clearing out implementation bugs in the browsers. Now, when you look at what has been developing in the last few years with content security policies, strict transport security, etc., you are seeing much more innovation within the Web protocols. In addition, the industry now has the resources to do proactive work such as Private Mode browsing, phishing protections and cross-site scripting mitigations. The contributions to documentation from independent researchers, vendors and groups such as OWASP have greatly assisted the application security community. Adobe is fully participating in this innovation to ensure that our plugins, SDKs and documentation can support these advancements. Ultimately, all of this work will make its way into the hands of web developers, who can use these tools to improve the security of their websites.
DS: Adobe Reader is among the world's most exploited applications, next to Oracle's Java and Microsoft programs. How Adobe's concern about that? PU: Adobe products are relied on by individuals and organizations worldwide. Because Adobe Reader is so widely deployed, Adobe has attracted—and will likely continue to attract—increasing attention from attackers and the security community at large. However, Adobe employs industry-leading security software engineering practices and processes in building our products and responding to security issues, and the security of our customers will always be a critical priority for us.
DS: I suppose that Adobe receives many false and positive security alerts. What's the process to fix and publish a report on a vulnerability? PU: Adobe has a team in place, the Product Security Incident Response Team (or PSIRT), that is dedicated to responding to security issues discovered by external security researchers, partners, customers and others after a product ships.
Once Adobe PSIRT receives information about a security issue, the team responds to the person who reported the issue--let's just say the security researcher. We acknowledge the report and ask for a proof-of-concept file to demonstrate the vulnerability, if applicable. Adobe PSIRT logs the issue in the Incident Response Database for tracking purposes. An Incident ID is automatically generated at this point and passed along to the researcher.
Adobe PSIRT then sends the report to the relevant product team’s Product Security Response Team (or PSRT) for verification. The product team’s PSRT includes a collection of development, quality and program managers, along with developers, quality engineers and product managers.
The Adobe Secure Software Engineering Team (or ASSET) helps reproduce the bug and assists the product team with the severity analysis. If reproducible, the product team (or ASSET, if appropriate) logs an internal Adobe bug for the issue.
Next, the product team investigates the issue and develops a fix, or workaround. ASSET helps to verify the fix. Any fix will be ported to all supported versions, as well as any version(s) currently under development.
If the vulnerability is verified, Adobe PSIRT responds back to the researcher, informing him that the issue has been reproduced and a fix is being investigated. As soon as possible, Adobe PSIRT communicates a proposed timeline for a patch to the researcher. Adobe always encourages the responsible disclosure of vulnerabilities in our products, so the researcher is asked to keep the vulnerability confidential until a fix is available. Our goal is to keep our customers as secure as possible, so we want to keep the vulnerability information from malicious hackers.
The product team produces patches for all supported product versions, as quickly as possible. Adobe PSIRT passes along any relevant status updates to the researcher and answers any questions he may have.
Once available, Adobe PSIRT passes the patch to the researcher for verification, if possible. Adobe PSIRT also sends the Security Bulletin text to the researcher for review and works with MITRE Corporation to generate CVE identifiers for the issues being addressed.
Finally, the Security Bulletin is posted to http://www.adobe.com/support/security/, and the product patch(es) are made available to customers.
For more information on the PSIRT process, check out our ASSET blog post on the topic at http://blogs.adobe.com/asset/2009/01/adobe_psirt_process_1.html.
DS: Adobe Reader X will have a sandboxing architecture designed to provide better security to users. Could you explain how that works? PU: The Adobe Reader sandbox (to be called Protected Mode in Adobe Reader X) 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 Reader Protected Mode will be enabled by default in Adobe Reader X. 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 (such as 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.
We recently kicked off a series of blog posts, which examine the technology behind Adobe Reader Protected Mode in more detail. The following blog posts on the implementation are already available—with additional posts to follow:
•Adobe Secure Software Engineering Team (ASSET) Blog Post: Inside Adobe Reader Protected Mode - Part 2 – The Sandbox Process (October 25, 2010) (Authors: Kyle Randolph, Liz McQuarrie, Ashutosh Mehra, Suchit Mishra and Ben Rogers)http://blogs.adobe.com/asset/2010/10/inside-adobe-reader-protected-mode-
Part three in our series “Inside Adobe Reader Protected Mode” is scheduled to be posted on Monday, November 1.
DS: Do you think sandboxing PDF's enough? PU: While sandboxing technology is not a silver bullet, 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.
In addition to the platform attack mitigation s in place in Adobe Reader 9—namely Data Execution Prevention (DEP)—Adobe Reader X Protected Mode implements the following platform mitigations for both the sandbox process and the broker process:
These mitigations combined provide a significant hurdle for an attacker using a malicious PDF file as an attack vector. Even if an attacker manages to overcome these hurdles and exploit a vulnerability in Adobe Reader X inside the sandbox, he would still need to exploit a second vulnerability in the Adobe Reader broker process in order to attempt to elevate privileges. Because the broker process also has all of the above platform mitigations enabled (DEP, ASLR, SEHOP), the attacker would have to overcome the same hurdles in the broker process. Even if the attacker gets this far, on Windows Vista and later, he will still not be able take full control of the machine. The broker process does not run with an administrator SID enabled on these platforms, so the attacker would have to exploit another local privilege escalation vulnerability at this point to successfully complete the attack.
That said, with Adobe Reader Protected Mode, the attacker needs to overcome five different hurdles instead of two in order to succeed in this traditional attack vector for installing persistent malware—a significant improvement in attack mitigation.
DS: What about Flash security? What's the next step? PU: We are actually moving forward in several areas all at once. At the operating system layer, we are working on JIT spray mitigations, improved sandboxing and other initiatives to limit the impact of vulnerabilities on end-users and enterprises. One example is that we recently added support for the Microsoft System Center Updates Publisher (SCUP). At the browser integration layer, we are actively working on improving the interaction between the browser and plugin. Some examples include our work on the proposed Pepper API, supporting private mode browsing and working with the browser groups to ensure that we can support their upcoming improvements. For our development community, we are researching new ways to allow them to better manage and control content, such as the recently introduced allowCodeImport flag. For end-users, we are working on providing better ways for them to control their privacy online. Our approach to security requires that we look for improvements throughout the entire product. I think that 2011 will bring some exciting advancements for the Flash community.
DS: Does Adobe have any new security measures in the pipeline that may help make the web a safer place? PU: I think that some of the most interesting work that we are doing is our collaboration with partners. For instance, we worked with the Google Chrome browser team to enable an automatic update of Adobe Flash Player whenever the end-user's browser is updated. I have been working with OWASP on the OWASP Flash Security Project. The goal of the project is to provide a centralized resource for Flash security that contains both Adobe and third-party research. We are also collaborating closely with Microsoft; as part of this collaboration Adobe started sharing Adobe vulnerability information with security vendors via the Microsoft Active Protections Program (or MAPP). This partnership allows us to help improve the AV, IDS and general security infrastructure that protects end-users when a vulnerability is identified. Ultimately, our plugins are an extension of a much larger ecosystem, and the best security solutions are achieved when we work together. In 2011, end-users will see direct improvements to our platform, but they will also see us increasing our collaboration with our partners.
DS: To end this interview, do you have some final words to our Portuguese readers? PU: The most important advice for consumers, regardless of the product they are using, is to always stay current on the latest security updates. As I mentioned earlier, the majority of attacks we are seeing are exploiting software installations that are not up-to-date. This is why we always strongly recommend that users follow security best practices by installing the latest security updates as the best possible defense against attackers.
In the meantime, Adobe will continue to improve the security of our products and platforms through our secure product lifecycle (SPLC) to help ensure end-users have less to worry about and developers are empowered to create more secure applications. People can follow the advancements we are making in our products by following our blog at http://blogs.adobe.com/asset.
Use your Facebook login and see what your friends are reading and sharing.
Now bringing you back...