On a lighter note, Team Adobe—consisting of Brad Arkin, Domingo Montanaro (general manager at iSIGHT Partners Brazil) and me—bagged the “Security Jeopardy” competition at the event on Friday evening. The winning answer only our team could come up with, ironically: “What is ‘zero knowledge.’”

Until the next conference!

Karthik

Today, Adobe has launched a public beta of our new Flash Player sandbox (aka “Protected Mode”) for the Firefox browser. The design of this sandbox is similar to what Adobe delivered with Adobe Reader X Protected Mode and follows the same Practical Windows Sandboxing approach. Like the Adobe Reader X sandbox, Flash Player will establish a low integrity, highly restricted process that must communicate through a broker to limit its privileged activities. The sandboxed process is restricted with the same job limits and privilege restrictions as the Adobe Reader Protected Mode implementation. Adobe Flash Player Protected Mode for Firefox 4.0 or later will be supported on both Windows Vista and Windows 7. We would like to thank the Mozilla team for assisting us with some of the more challenging browser integration bugs. For Flash Player, this is the next evolutionary step in protecting our customers.

Sandboxing technology has proven very effective in protecting users by increasing the cost and complexity of authoring effective exploits. For example, since its launch in November 2010, we have not seen a single successful exploit in the wild against Adobe Reader X. We hope to see similar results with the Flash Player sandbox for Firefox once the final version is released later this year. In the meantime, please help us get these protections out to end-users as fast as possible by volunteering to download our beta and help test. Information on known bugs, configuration options and other information can be found on Adobe Labs in the “Getting Started” section.

P.S.: I will be speaking at CanSecWest on this and other exciting topics. I hope to see everyone there!

JavaScript Whitelisting Capability

Adobe Reader and Acrobat allow administrators to disable the execution of JavaScript embedded in PDF files, a potential attack vector for exploits. While doing so provides mitigation against JavaScript-based vulnerabilities, it also breaks PDF-based solution workflows that rely on forms and JavaScript.

The new JavaScript whitelisting capability introduced in Adobe Reader and Acrobat X (10.1.2) and 9.5 allows JavaScript execution in PDF files based on document trust. If a document is trusted, JavaScript execution will be allowed; but if it is untrusted, Adobe Reader and Acrobat will prevent all JavaScript execution. The trust decision is based on Privileged Locations.

With this capability, two additional admin controls have been added:

• JavaScript Lockdown
• Provides administrators the ability to lock down all JavaScript execution, except when embedded in trusted documents, and prevent users from enabling JavaScript from the user interface/preferences

• AdminTrusted Locations
  • Provides administrators the ability to add trusted locations

In case administrators want to completely disable all JavaScript execution, including the execution of JavaScript in trusted PDF files, they can take advantage of the “Javascript lockdown” capability along with the “Disable Trusted Location” capability, which prevents users from adding Privileged Locations.

Please refer to the release notes for more details.

Steve Gottwals, Group Product Manager, Adobe Reader
Priyank Choudhury, Security Researcher, Adobe Secure Software Engineering Team (ASSET)

• We are planning to release an out-of-cycle security update for Adobe Reader and Acrobat 9.x for Windows no later than the week of December 12, 2011.
• Because Adobe Reader X Protected Mode and Adobe Acrobat X Protected View would prevent an exploit targeting this vulnerability from executing, we are planning to address this issue in Adobe Reader and Acrobat X for Windows with the next quarterly security update on January 10, 2012.
• The risk to Macintosh and UNIX users is significantly lower. We are therefore planning to address this issue in Adobe Reader and Acrobat X and earlier versions for Macintosh as part of the next quarterly update on January 10, 2012. An update to address this issue in Adobe Reader 9.x for UNIX is planned for January 10, 2012.

The reason for addressing this issue quickly for Adobe Reader and Acrobat 9.4.6 for Windows is simple: This is the version and platform currently being targeted. All real-world attack activity, both in this instance and historically, is limited to Adobe Reader on Windows. We have not received any reports to date of malicious PDFs being used to exploit Adobe Reader or Acrobat for Macintosh or UNIX for this CVE (or any other CVE).

Focusing this release on just Adobe Reader and Acrobat 9.x for Windows also allows us to ship the update much earlier. We are conscious of the upcoming holidays and are working to get this patch out as soon as possible to allow time to deploy the update before users and staff begin time off. Ultimately the decision comes down to what we can do to best mitigate threats to our customers.

I’d like to take this moment to encourage any remaining users still running Adobe Reader or Acrobat 9.x (or worse, older unsupported versions) to PLEASE upgrade to Adobe Reader or Acrobat X. We put a tremendous amount of work into securing Adobe Reader and Acrobat X, and, to date, there has not been a single piece of malware identified that is effective against a version X install. Help us help you by running the latest version of the software!

Of the more than 40 organizations that have conducted a BSIMM measurement, 25 were represented by 77 attendees at last week’s BSIMM community event. This group made for a very interesting subset of the broader security community because everyone is focused narrowly on practical defensive software security. Typically, offensive security topics tend to dominate most of the security conferences I attend. Even the conference talks that are supposedly about defensive topics tend to be more focused on how to employ offensive techniques during testing rather than on providing a holistic view of real-world defensive software security. So, it is refreshing and exciting when someone tries to rally attention towards research into truly defensive techniques. (The Microsoft BlueHat Prize announced at BlackHat this past summer or the exchanges among the members of SAFECode are other examples that come to mind.)

I presented “Adobe Product Security Through the BSIMM Lens: 2008-2011″ on the first day of the BSIMM event and attended a number of interesting talks. However, the most valuable part of the event, as is always the case, was the “hallway track.” The chance to compare notes with peers from other organizations tackling the same technical problems with such widely varying resources, priorities and definitions of success was the reason I attended, and I wasn’t disappointed.

To sum it up, the BSIMM community event was a great opportunity to spend time with like-minded folks from across the industry.  I’m looking forward to next year.

Adobe joined SAFECode (the Software Assurance Forum for Excellence in Code) in 2009. You can read a bit about what I was hoping Adobe would gain from its SAFECode membership in a Q&A posted at the time to the SAFECode blog. Since we joined, we’ve contributed to a couple of major publications—the Fundamental Practices for Secure Software Development paper and an Overview of Software Integrity Controls—as well as numerous smaller efforts.

However, the biggest value Adobe has gained from its SAFECode membership comes from the very frequent interactions we have at all levels with our peers from the secure software engineering teams of SAFECode member firms. From comparing external communication strategies to technical release checklists and tooling, the benefit of tapping into a community of people tackling the same challenges can not be overstated.

Expanding this community to include the Siemens security folks is a big win for the SAFECode community and will help accelerate the hard work Siemens is putting into securing their software. SAFECode is always on the lookout for prospective new members, so if you think your organization might be a fit, please get in touch. You can learn more about SAFECode here.

Coinciding with the first day of the conference, Microsoft today released volume 11 of its Security Intelligence Report (SIR). One of the key take-aways is the importance for users to stay up-to-date. Microsoft’s findings show that less than one percent of exploits in the first half of 2011 were against zero-day vulnerabilities—or in other words: More than 99 percent of exploits in the first half of 2011 were targeting outdated installations, exploiting vulnerabilities for which a fix was already available. But don’t take my word for it; give the report a read. It provides valuable insight into global online threats, including zero-days, which help customers better prioritize defenses to more effectively manage risk.

Extending Key Privacy Capabilities to Mobile Devices

Adobe has been working hard to make it easier for users to control their privacy and privacy settings on their desktops. We added support for the private browsing feature found in many Web browsers when we introduced Flash Player 10.1, created a desktop version of the Flash Player Settings Manager (aka a native control panel) and redesigned the Flash Player Settings Manager interface in Flash Player 10.3. And we worked closely with the browser community to allow end-users to clear their Local Shared Objects (LSOs) through their existing browser controls—functionality that was also introduced in Flash Player with the release of Flash Player 10.3.

With Flash Player 11, we are extending key privacy capabilities to tablets and mobile devices. Privacy is important regardless of the device you are using. With the release of Flash Player 11, we are bringing support for private browsing mode (aka incognito mode)* and a mobile control panel to Android devices. This means that end-users will be able to leverage the same private browsing mode protections available to them on their desktops today on their mobile devices, while the new mobile control panel will make it easier for them to manage their Flash Player privacy settings on their Android devices. (*Private browsing mode, or incognito mode, is supported on Android Honeycomb.)

The mobile control panel will launch the browser on the device and take the user to the online mobile settings manager, which allows users to control two of the mobile Flash Player features:

• The first are the settings for controlling Local Shared Objects (LSOs). Users can choose to “always” allow local storage, allow local storage “only from sites I visit” or “never” allow local storage. The settings manager also provides a handy “clear [all] local storage” option.
• The second feature that can be controlled is peer-assisted networking which allows Flash Player to use connection sharing to provide a better media experience.

New Security Features in Flash Player 11

On the security front, we are introducing several new features that will allow developers to better protect customer data. The first major new feature we are adding is support for SSL socket connections, which will make it easier for developers to protect the data they stream over the Flash Player raw socket connections.

We are also adding a secure random number generator. Flash Player previously provided a basic, random number generator through Math.random. This was good enough for games and other lighter-weight use cases, but it didn’t meet the complete cryptographic standards for random number generation. The new random number generator API hooks the cryptographic provider of the host device, such as the CryptGenRandom function in Microsoft CAPI on Windows, for generating the random number. The native OS cryptographic providers have better sources of entropy and have been peer reviewed by industry experts.

Lastly, the introduction of 64-bit support in Flash Player 11 brings with it some security side-benefits: If you are using a 64-bit browser that supports address space layout randomization (ASLR) in conjunction with the 64-bit version of Flash Player, you will be protected by 64-bit ASLR. Traditional 32-bit ASLR only has a small number of bits available in the memory address for randomizing locations. Memory addresses based on 64-bit registers have a wider range of free bits for randomization, increasing the effectiveness of ASLR.

Overall, our security and privacy roadmap still has much more to come, and we are already working on the next generation of features for upcoming releases. To take a look at the many new features in Flash Player 11—whether it be the advancements for gaming, media and data-driven applications, the security enhancements or the new mobile privacy features—check out the release candidate of Flash Player 11 for desktops now available on Adobe Labs or watch for an announcement once Flash Player 11 for desktops and Android devices becomes available in early October. We look forward to your feedback!

Lindsey Wegrzyn, Senior Product Manager, Privacy
Peleus Uhley, Platform Security Strategist

JavaScript exploits used to be one of the main attack vectors for Adobe Reader as well as the PDF format in general. In October 2009, Adobe introduced a series of security enhancements for managing JavaScript execution within Adobe Reader and Acrobat, all of which are described here.

One of these, the JavaScript API blacklist, proved invaluable only two months later when attackers launched targeted attacks against CVE-2009-4324. Both end-users and enterprises were able to completely mitigate attacks exploiting this vulnerability by blacklisting the individual JavaScript API. Since the technique simply involves adding new registry value entry to a particular registry key, some organizations we talked to were able to deploy a Group Policy Object with the updated registry entry to hundreds of thousands of machines within 24 hours.

To further refine this process for enterprise IT, the security team created a tool with a user interface for this feature, and it is now available on Adobe Labs.

Blacklist Tool Screenshot

The tool presents a list of JavaScript APIs that have been attacked in the past. It retrieves this list of APIs from an Adobe server. If an Internet connection is unavailable, it presents a default list. When you click on ‘View,’ it displays the current entries in the JavaScript Blacklist and saves this data in a text file in the directory the application is running from (usually its installation directory). You can check multiple APIs then ‘Add’ them to the JavaScript Blacklist or Remove them. Simple enough!

Note that the tool requires the Microsoft .NET 4.0 framework. The tool’s installer should prompt you to install dependencies automatically.

If you are a Windows sysadmin and have had to make changes to the JavaScript Blacklist by hand, this tool will make your life a little easier. To download the tool, visit Adobe Labs at http://labs.adobe.com/technologies/acrobat_ittools/. The tool will work with the JavaScript Blacklist Framework on Reader 9.2 and 8.1.7 and later versions (including Reader X and Acrobat X) on Windows.

Karthik Raman, Security Researcher, PSIRT
Ben Rogers, Technical Writer, Acrobat & Reader Engineering

cve.mitre.org 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