Archive for August, 2011

How Did You Get to that Number?

There’s been some chatter about CVE numbers lately, so I thought it would be helpful to clarify Adobe’s position on how we use CVEs to communicate product security information. describes them as “international in scope and free for public use, CVE is a dictionary of publicly known information security vulnerabilities and exposures.”

Unfortunately, there are many differences in opinion on how CVEs should be used in real-world situations. If there are four instances of unsafe buffer usage resolved with a single buffer size check, does that represent four CVEs or just one? If vulnerable code is copied and pasted into multiple products, should the vulnerable line of code be described with a single CVE or one unique CVE for each product? How does the answer change, if the product is vulnerable because of linking a vulnerable library rather than copied-and-pasted code? The real-world questions go on and on….

In response to these ambiguities, software producers and the security community have done the best they can. CVE allocation tends to be fairly consistent within a product or organization over time, but there can be significant differences when you compare one vendor’s practices to another’s. This is one of the reasons why blind CVE counting to compare different products is usually a bad way to assess their relative security.

Here are some rules of the road Adobe follows when it comes to CVE allocation:

  • Any externally reported vulnerability gets assigned a CVE that is listed in the security bulletin. (In this age of fuzzers, it can be difficult to determine when a set of crasher input files triggers the same or different vulnerabilities. It’s not unusual for us to see a large number of crashers with different hashes get resolved by a single bug fix in the code.)
  • Any zero-day or in-the-wild exploit triggers a CVE assignment to describe the vulnerability targeted by the exploit.
  • Any bug identified by Adobe engineers and resolved as part of the Adobe Secure Product Lifecycle (SPLC) is not assigned a CVE. In looking at the CVE description, we do not consider these bugs “publicly known.” Following the same reasoning, any bug identified by consultants, contractors or partners as part of their joint engineering effort/work with Adobe is also not assigned a CVE.

These rules of the road are just a starting point. There are many examples of complicated real-world scenarios where we’ve had to make precedent-setting decisions. We always try to stay consistent with the guidance from Mitre and our own internal precedents. We also frequently compare notes with other software producers and our friends in the security community to collect ideas on how we can improve our internal approach. Since the whole point of using CVEs is to help facilitate communication about software vulnerabilities, our goal is to use CVEs in the same manner as other ISVs to avoid any potential confusion within the industry.

The Flash Player update released on August 9, 2011 presented us with a new situation. We issued a ‘critical’ security bulletin that described 13 CVEs reported to us by external sources. In the ‘Acknowledgments’ section, we also thanked Tavis Ormandy and the Google Chrome team for their great work in helping us harden this release of Flash Player. We didn’t allocate any CVEs because we viewed this testing as part of the SPLC that spans the joint engineering efforts with the Google Chrome team. This led to some confusion since the Google security team has a different approach to CVE allocation.

The initial run of the ongoing effort resulted in about 400 unique crash signatures, which were logged as 106 individual security bugs following the initial triage. As these bugs were resolved, many were identified as duplicates that weren’t caught during the initial triage. In the final analysis, the Flash Player update we shipped earlier this week contains about 80 code changes to fix these bugs.

So, what’s the right number of CVEs to allocate? In this particular case, some of the code changes we made were closely related within a single component, which would argue for consolidating them with a single CVE, while others were clearly distinct. At this point, we’d rather invest our time in continuing the hardening work that will make Flash Player more robust against attack than reviewing change logs. We’ve updated the security bulletin to include CVE-2011-2424 to describe this batch of bugs.

What’s most important is that industry partners like Google and Adobe are working together on projects like this to protect our mutual customers. Adobe greatly appreciates the assistance of the Google Chrome team on this and other projects that are part of our cooperation.

Brad Arkin
Senior Director of Product Security and Privacy

PDF Encryption Options



There are three main ways to encrypt a PDF file:

  1. Password encryption
  2. Public Key Infrastructure (PKI) encryption
  3. Rights Management






Onward to the Desert Oasis: Black Hat USA 2011 – Las Vegas

Hi there!

Steve here again, to let everyone know what the Adobe’s security team is up to. This week the team heads to the desert to take part in one of the best annual security events, the Black Hat USA 2011 security conference in Las Vegas.

A key part of the Adobe security strategy is centered on collaboration and engagement. This is one reason why Black hat is important to us. This year, we are happy to be engaged in the following ways.

The rest of the team will be taking in talks on new security topics and answering questions on what Adobe is up to in the area of security.

We will also have a hospitality suite in Caesars palace (conference hotel) to make it easier for people to take a break, stop by and have a chat with us.

Adobe is looking forward to seeing you there!


Steve “Capn Steve” Adegbite