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

If you have sensitive information you want to protect and distribute, PDF is a good option to consider.  Adobe Reader could very well be the most widely distributed crypto-enabled application from any vendor, because Adobe has been including encryption since version 2.0 in 1994 – across numerous desktop and mobile platforms.   So there’s a pretty good chance that your intended recipients will be able to open an encrypted PDF.  Today in 2011, PDF supports the FIPS certified AES 256 algorithm and provides a number of advanced capabilities.

Another advantage of using the built in encryption of PDF is that it can be persistently integrated in the file – and not enveloped.  This means that anywhere the file goes, independent of storage and transport, it stays protected.  Common alternatives like PGP, ZIP, and S/MIME use enveloping encryption around content that gets discarded when the envelope is open – leaving the content unprotected, subject to accidental or malicious redistribution.

There are three main ways to encrypt a PDF file:

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

Password encryption relies on a shared password between the publisher and all the recipients.  The publisher selects a phrase like “No1Kn0w$” to encrypt the document, and the recipient uses the same to decrypt it.  To mitigate brute force attacks as well as simple guessing of common passwords – be sure to use long complex passwords with multiple upper, lower, number, and symbol combinations.  Remember to be creative, like song lyrics, poetry, and other long phrases as source material.

PKI encryption can provide greater protection by using additional cryptography and digital certificates.  Each recipient has a keypair (up to RSA4096), and publishes their public key certificate.  While encrypting, the publisher’s computer randomly generates a symmetric key(up to AES256), and encrypts that key to each recipient’s asymmetric public key to include in the document with the symmetric key encrypted content.  In return, the recipient computer uses their own private key to decrypt the symmetric key, and then decrypt the document.  When the private key is stored on a token, e.g. USB, CAC, PIV, eID – it can provide two factor security – requiring the token, and any PIN codes to unlock the token.

Rights Management was developed to provide integration into enterprise authentication (AuthN) and authorization (AuthZ) infrastructure without requiring PKI.  A Rights Management server ties into LDAP, Active Directory (AD), or other user databases to identify the ecosystem of users sharing a document.  Rights Management can also use those same directories to read in groups of users.  An administrator can create a rights management “policy” which is an easily reusable way to protect documents in a certain way.  The policy can define which users or groups can open the document, what they can do with the document, and track what they have done with the document.  These can be internal or external users – whether employees, partners, or consumers.  The publisher then selects the policy to protect a document.  The recipient opens the document and the Acrobat/Reader client will call back to the server to authenticate them, then determine whether they are authorized to open the document.  In addition to username/password types of authentication, the server can also support Kerberos single sign on (SSO),PKI authentication (which is different than PKI encryption above), OTP, and other custom methods.  With Rights Management you can also expire, revoke, version control, watermark, and audit document usage, too.  Rights Management is great for communities of users that have existing authentication and authorization systems in place – whether it’s secure information sharing, or electronic statements to consumers.  In addition to PDF, Rights Management can also apply to native Office and CAD documents, too.  Stay tuned for news on rights management capabilities being available on smartphone and tablet devices in Fall’11, too!

For all three encryption methods, it is also possible to restrict printing, clipboard, and modification after a protected document is opened.

Applying these encryption capabilities can be done ad-hoc on the desktop with Acrobat, as well as part of automated structured workflows on a server, too.

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