Interview with Peleus Uhley by David Sopas

www.websegura.net

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.

The majority of attacks we are seeing are exploiting software installations that are not up-
to-date on the latest security updates. We therefore always strongly recommend that users
follow security best practices by installing the latest security updates as the best possible
defense. To make this process even easier, Adobe introduced a new updater for Adobe
Reader and Acrobat. The new updater is designed to keep end-users up-to-date in a much
more streamlined and automated way. 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. More information on the new updater is available on
the Adobe Reader blog at
http://blogs.adobe.com/adobereader/2010/04/upcoming_adobe_reader_and_acro.html.
DS: Javascript is often by malicious users to infect PDF. What's your opinion about it and
why is javascript enabled in Adobe Reader?
PU: JavaScript provides one of the easiest and most powerful ways to customize PDF
files. JavaScript functionality is what enables users to manipulate PDF files, produce
database-driven PDF files, modify the appearance of PDF files, and what facilitates
support for multimedia, improved printing control, controlling layers, 3D support, and so
much more. It is also particularly useful for XML forms. JavaScript enables automated
forms handling, Web and database communication, commenting, and user-interface
capabilities. All of this is functionality that users have come to rely on today.

JavaScript is enabled in Adobe Reader by default to ensure our customers have the user
experience they have come to expect. The majority of our customers rely on functionality
and workflows that would break if JavaScript were disabled by default.

However, because JavaScript has become one of the main attack vectors for PDF and
Adobe Reader, we included a number of security enhancements around Adobe Reader
and Acrobat’s handling of JavaScript with the quarterly Adobe Reader and Acrobat update
in October 2009. These include the ability for customers who don’t rely on this functionality
to disable JavaScript using an improved “gold bar” user interface (an improvement from
the previous pop-up box), significant improvements to strengthen input validation on all
JavaScript calls, as well as the introduction of a JavaScript blacklisting mechanism. The
JavaScript Blacklist Framework provides customers with granular control over the
execution of specific JavaScript API calls, allowing them to add JavaScript API calls to the
blacklist and block them from executing. Organizations can even block specific JavaScript
API calls and keep their end-users from overriding that decision.

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: Introducing Adobe
Reader Protected Mode (July 20, 2010)(Author: Brad Arkin, Senior Director of
Product Security and Privacy)http://blogs.adobe.com/asset/2010/07/ introducing-adobe-
 reader-protected-mode.html
• Adobe Secure Software Engineering Team (ASSET) Blog Post: Inside Adobe
Reader Protected Mode – Part 1 – Design (October 5, 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-1-
design.html
• 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-
%e2%80%93-part-2-%e2%80%93-the-sandbox-process.html

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:
• Data Execution Prevention (DEP)
• Address Space Layout Randomization (ASLR)
• Structured Exception Handling Overwrite Protection (SEHOP)

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.