Adobe: Bug reporting and the sandbox

Adobe: Bug reporting and the sandbox

Adobe: Bug reporting and the sandbox

Date: Aug 11, 2010

Brad Arkin talks about Adobe's policy on "bug bounties" and why it's decided to play in a "sandbox."

View more in this series:


Read the full text transcript from this video below. Please note the full transcript is for reference only and may include limited inaccuracies. To suggest a transcript correction, contact editor@searchsecurity.com.   

Adobe: Bug reporting and the sandbox

Interviewer: How do you expect Bug Hunters to disclose bugs? What is
Adobe's policy? We have heard a lot this week about Microsoft's
responsible disclosure policy.

Brad Arkin: That blog post that I mentioned our asset blog lays out, and
there is actually a graphic that shows the workflow of how
things happen. Any time a researcher identifies a potential
security vulnerability in an Adobe product we are thrilled to
hear that research, and you can contact us through
PSIRT@adobe.com or there is a web input, where you can just post
into a form field then hit submit; either way it will come to
us. We will look at it, we will get in touch, and a lot of stuff
comes into that email list that is not, it is garbage, spam, or
things like that, so we triage through that. Anything that has
any chance of having technical merit, we try to initiate contact
with the person who reported it to us, then we triage it our
side, can we see the same results that the researcher saw? If
so, then we will say, 'This looks useful. Thank you very much
for sharing. We are going to work with the product team.' Then
the product team works on creating bugs, doing the testing,
doing the development to make sure that they fixed it, and the
end result is eventually, a security update that will ship, then
security bulletin we will describe it with the CDE a little bit
of other information, and thank the researcher.

For us, there is a small group of researchers that we have very
extensive relationships with, and we work a lot with them, then
there is always someone new who maybe has not reported to us
before, we might know them in the security community. Our goals
through all of this are, always make it clear how very
appreciative we are that they have taken the time to share this
information with us and to everything we can to keep them up to
date on what is happening. Adobe is a big company with thousands
of people, these products are huge, and we are making lots of
changes, so we try to keep them up to date on exactly what is
happening, what is the state of the bug? Is it confirmed? Is it
fixed yet, will it be in the next release or not? That has
worked really well for us. We value the researchers and we try
to show that in the way we interact with them. It has been going
pretty well.

Interviewer: Why not pay researchers for the bugs they find?

Brad Arkin: For us, we spent a lot of money on external researchers helping
us to improve our software, and rather than some type of bug
bounty, what we have chosen to do is if anyone comes to us and
says, "I got some great ideas for making your software better,'
whether it's testing or other ideas, we look at a potential
consulting engagement. The effectiveness of the experience and
the skills that that researcher brings is so much higher when
they are able to access the engineers directly working on the
product, and access our design documents, and all the internal
stuff that can help them really do a full white box assessment,
whereas it is a lot harder and slower to do it externally. When
I look at how we can best improve our software, that is the way
that we have chosen to do it. Things are changing fast in the
industry, so we are really paying attention to see if some of
these other approaches might work in our environment. Nothing is
set in stone for us, it is just this is what we are doing right
now.

Interviewer: Talk about the Sandboxing. This is a new announcement you
came out with, last week or the week before.

Brad Arkin: Tuesday, July 20th, is when we came out with that, and this is
something we are really excited about. When we looked at Reader
and we looked at all the different ideas to make Reader more
secure against this new type of threat that we are seeing, we
had to balance all of these ideas against the fact that there is
hundreds of millions of people that use Reader in a particular
way today, and they do not want to have to change. How can we
make them safer without asking them to change the way they
interact with the product? Sandboxing is one of the things that
made it through the initial process, and we made a big
investment to implement this.

We started this summer of '09, or early summer, and we made the
announcement last week that we were going to test Sandboxing in
the next major version of Adobe Reader. The first release is
going to be write-only, so the Sandbox will run Reader in a low
process, low-rates process. If an attacker found a vulnerability
in the product that today might allow them to take over the
computer, in the future, with Sandboxing, they will be stuck in
the sandbox, initially that means they will not be able to write
to the machine, install software, or tamper with the registry.
We intend, in a second phase, to extend that Sandbox to read-
only activities as well, so that an attacker in the Sandbox will
not be able to read the hard drive, read the file system, or
read the registry.

Reader has a lot of situations where it does need to actually,
legitimately contact and make changes to these resources, so we
had to implement a broker process that is able to proxy through
these requests. Taking a product with such a history as Reader,
retrofitting a Sandbox onto it, making sure that everything
works the way it used to without any change, is a significant
investment, it took a lot of work. The team has been working
very hard for more than a year, and we expect to get this out to
our users before the end of 2010.

Interviewer: Reader works on its own and also as a plug-in with a
browser. Can you Sandbox it in both?

Brad Arkin: That is right. We are actually, something that is really
exciting here is that not only is the web browser plug-in
Sandboxed, regardless of any browser you use, the standalone is
Sandboxed as well, so if you double-click an email attachment
and it opens up in Reader, that is Sandboxed, also the file
extension. In your file extension, if you see a preview of the
document, Reader is actually the one that previews that to the
user, and we are Sandboxing that as well.

We have really looked at all the different potential threats,
and how Sandboxing can help address those. With our
implementation, our goal is that we can achieve the potential of
what Sandboxing offers. This has already been demonstrated with
Google Chrome, Microsoft Office Protected View in 2010. These
are Sandboxes that are out there today that use the same
technique, and we have worked really closely with the Google
folks and the Microsoft folks who have experience with this,
because with Reader we are really pushing the technique in
directions it is never gone before, so leveraging their success
and what they have already done, then working together to figure
out how to move over these new obstacles was really important
for us.

More on Security Testing and Ethical Hacking

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: