Adobe: Flash security and the Microsoft Active Protections Program

Adobe: Flash security and the Microsoft Active Protections Program

Date: Aug 16, 2010

Brad Arkin discusses Adobe's strategy to secure Flash Player and its decision to join the Microsoft Active Protections Program.

View more in this series:

Read the full transcript from this video below:  

Adobe: Flash security and the Microsoft Active Protections Program

Interviewer: Let's talk about Flash. You've addressed Adobe Reader and
Acrobat. How can you address Flash issues? It's targeted so much.

Brad Arkin: That's right. Flash Player is installed on a lot of machines and so
in the same way that Reader gets a lot of attention, so does Flash Player.
So, our secure product life cycle, all those steps that we follow, the
static code analysis, manual analysis, plus testing, all of these
things are happening for Flash Player, too.

We talked about the sandboxing technique. For a couple of years now, Flash
Player has opted into Internet Explorer Protected Mode. This is if you're
running IE 7 or 8 or later, and you're running Windows Vista or Windows 7,
or later. Then, this Internet Explorer Protected Mode, similar to the
sandbox that we did for Reader, which is low rights, use a broker process
in order to communicate, if you need to do something that are higher
rights.

So, that's something that we've had in place for a while, and we have a lot
of other things that were working on with Flash Player, as well. So, in the
10.1 version that just shipped, Flash Player now hooks into the privacy
mode settings for the browser. So, if you do any kind of incognito mode or
privacy mode or whatever it's called, Flash Player now is able to tap into
that and then respect those settings. So, Flash LSOs or any other
information that usually would tell the Weather Channel like what your ZIP
code is and that sort of thing, none of that will be available, when you're
using the regular browser in Protected Mode. So, that's just one little
thing that we've done.

There are a lot of other activities that are happening. So, every release
for Flash Player, for Reader or Shockwave, every release is getting better
for security, and then each of the major products have their own roadmaps
of exactly what we're doing.

Interviewer: What has been the challenge with Flash? Is it because the code
has been around for so long and there wasn't necessarily, early on, in the
early days, a focus on security that these issues continue today?

Brad Arkin: Well, it's really the changes in the threat landscape. So, the way
the bad guys are going after the product, the way that they're going after
the design and the way it plugs into the Web browser, they're able to find
things which, in some cases, may have been very robust and secure for the
data of which they were written, but today there may be a new offensive
technique that makes it vulnerable.

And then, in other cases, we've got pretty much every bad guy, every
security researcher, every good guy proofreading our work here and looking
for any potential little flaw. So, when you're looking at any significant
code base, you're going to find lots of quality issues or potential
security issues, but most products don't get that attention. So, with
products like Reader and Flash Player, they're getting that attention, and
so the bar is much higher for us.

So, when you look at overall code quality, defect density and things like
that, Flash Player and Reader actually are very, very good. It's just that
a single misstep is all it takes in order to create a new vulnerability,
and so that's what bad guys are looking for.

Interviewer: How much responsibility should browser makers take in the
components that are within the browsers? Should they have any shared
responsibility?

Brad Arkin: Well, it's something where we all have to work together in order to
make the user experience in the browser as effective as possible. And so,
some things that we're doing, the Netscape plug-in API that Flash Player
uses, for instance, is something that was designed by Netscape, 10 or more
years ago. It's definitely showing its age. There are a lot of really cool
things that just aren't possible because the plug-in API wasn't built with
these things in mind.

There's a lot of mash-up stuff that we'd like to do that we can't because
the plug-in API won't let us. So, we're working with Google Chrome Team and
Mozilla and other browser makers on a project called Pepper, P-E-P-P-E-R,
and that's something that you can look at the page hosted on Mozilla and
it's got all the details about what's happening there. But that's the next
generation plug-in API that we're working on.

We are also working very closely with Microsoft, with IE, on things that we
can do in order to get Flash Player and IE working together better to,
overall, lead to a better user experience. So, when we look at the things
that we're doing with the security community, as a plug-in maker, we work
very closely with the browser folks because, ultimately, all of this code
is interacting together and it's up to us. The user doesn't care if the
fingers pointing and saying, "It's that guy's fault; it's that guy's
fault." They just want it to work. So, it's up to us to figure out how to
do that.

Interviewer: One of the announcements that you made here at Black Hat is
around joining the Microsoft Active Protections Program. Did I say that
right?

Brad Arkin: Yes.

Interviewer: Why did you decide to join that program? What does it mean for
the security vendors that are in that program?

Brad Arkin: For us, about a year and a half ago we were expanding our information
sharing programs and looking for ways to get this actionable detailed
technical information out to the security vendors so that they could help
protect our mutual customers against these types of attacks that were
possible. The feedback that we got, left and right, was that Active
Protection Program from Microsoft was the way to do it. So, they always
said, "Well, Microsoft does this. If you could do it more like that, that
would be better for us." So, we talked a lot with Microsoft to understand
what they're doing and how they got there and how they built it up.

It became obvious that we were in the process of reinventing the wheel. So,
rather than just doing it all over again, we worked together with Microsoft
to collaborate so that now Adobe product security information is going to
get shared through the MAP program, to these participants. So there's 65
now and Adobe's not becoming the 66th, but rather, we're becoming the
second software maker that's sharing product security vulnerability
information, whereas Microsoft used to be the only one.

So, for the protection providers, one day you might get information about
an IE bug, Microsoft Office and those are coming from very different parts
of Microsoft but, for the protection provider, it's all coming through that
channel. And now they're going to get information about Adobe products as
well, in the same technical format, same level of details, the same quality
consistency. It will just be about our products moving through that channel
and, ultimately, it's going to accelerate and improve the efficacy of the
protections they put in place. It's going to lead to safer experiences for
our mutual customers.

Interviewer: Let's talk mobile for a bit. Does Adobe have a mobile
strategy when it comes to security, and are there any lessons to be learned
from the desktop that can be applied to mobile?

Brad Arkin: We definitely do. For us, mobile is a really exciting new environment
to deploy into. At Adobe, we talked about the Open Screen Project that
we're doing, making sure that people can engage and interact with
information in the living room, on their handsets, on their desktops and on
all sorts of different types of devices. So, it's really important that we
carry over to that a safe and secure experience.

So, a lot of these handset devices, these days, are more powerful than
Pentium computers were from ten years ago. So, bad guys can have as much
mischief there as they were having ten years ago on these real machines,
desktop machines. So, there's no limitations. The difference is that these
new mobile platforms come with real exciting new capabilities, so they can
effectively sandbox different processes and if something goes wrong in one
place, it may not impact the rest of the phone or the other types of
devices.

So, our challenge is, generally, doing a good job for all of our regular
code hygiene and things that can make the code as robust as we can and
then, making sure we take advantage of all the new features that are
offered by these new platforms. And then, also working with our partners in
order to make sure they understand what these new threats are as they
change.

So, we'll use televisions for example. When was the last time you updated
firmware in your television? But, that's where we need to go once
television is going to start hosting really exciting new capabilities
because there's going to be a need to keep that updated. So, working on
what does the update mechanism look like and there are a lot of constraints
around there. So, there are definitely lots of industry-wide conversations
that are happening about how to deal with these potential threats before
they become a reality.

Interviewer: Well, Brad, thanks very much.

Brad Arkin: Yes. It's been a lot of fun. Thank you.

 

More on Securing Productivity Applications

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: