Author Archive: Adobe Product Security Incident Response Team

Digital Signatures with PIV and PIV-I Credentials

In response to Homeland Security Presidential Directive (HSPD) 12, NIST created a program for improving the identification and authentication of Federal employees and contractors to Federal facilities and information systems.  This program is Federal Information Processing Standard (FIPS) 201, entitled Personal Identity Verification (PIV) of Federal Employees and Contractors, which as of September 2011 had issued over 5 million credentials.  PIV-I expands the interoperable secure PKI credentialing to Non-Federal Issuers (NFI) so that other organizations seeking identity federation can include their own employees.  Currently approved PIV-I providers include DigiCert, Entrust, Operational Research Consultants, VeriSign/Symantec, and Verizon Business.  The CertiPath bridge also supports PIV-I credential providers such as Citi and HID.

If you have a PIV or PIV-I card, and are interested in digitally signing documents for consent/approval signatures or certified publishing – Adobe Acrobat and Adobe Reader will automatically validate digital signatures via US Federal Common Policy.  Through the Adobe Approved Trust List  (AATL) program, the following trust anchors are included in version 9 and higher:

  • Common Policy — 2010 expiry — Common Hardware, Common High, Medium HW CBP
  • Common Policy — 2027 expiry — Common Hardware, Common High, Medium HW CBP
  • Federal Common Policy CA — 2030 expiry — Common Hardware, Common High, Medium HW CBP, SHA1 Hardware
To have the digital signature automatically validate for any recipient, whether or not they have a PIV/PIV-I credential, the signer’s system must build a complete certificate chain for path validation to reach one of the supported trust anchors.  If the signer’s system only has the signer’s certificate – it will not validate for anyone else automatically.  A recommendation to make this easier is for all of the issuing certificate authority public key certificates to be stored on the smartcard and available to the OS+applications.  That way the card can be truly portable and sign documents on any system.  Otherwise, the system administrator will need to ensure all of the certificates are otherwise installed into the OS and available to Adobe Acrobat/Reader.
As an example, below is an overview of configuring digital signatures with the HID PIV-I service.
After the customer application is approved and credentials are being issued, the user will need to install the chain of certificates on their signing systems.  The certificates required are:
  1. HIDSigningCA1
  2. HIDRootCA1
  3. Federal Bridge CA
  4. CertiPath Bridge CA – G2

There are several ways these certificates can be installed.  The easiest is to open the attached file HID_PIV-I_AdobeConfiguration.pdf, which provides a simplified installation experience into Adobe Acrobat and Adobe Reader.  You can also download the FDF directly here:  HID-PIV-I-Certs-AdobeReader.fdf

Now you can sign a PDF file and it will automatically validate for anyone with Acrobat or Reader version 9.1 or higher.

Sample HID PIV-I Signature document digitally signed with a production HID PIV-I card looks like this:

Here is the path that the digital signature follows for validation:

FIPS Validation Certificate for LiveCycle ES3

Adobe LiveCycle ES3 includes a FIPS 140 Certified RSA BSAFE Crypto-J 3.5 (cert#590) encryption module.  FIPS mode is configured in the product installer.

CanSecWest 2012

The team and I are about to head off to CanSecWest. While I have been attending CanSecWest for several years, this year will be a unique experience for me. During my talk, I will demo an open-source tool I just released, called Adobe SWF Investigator. The tool can be useful for developers, quality engineers and security professionals for analyzing SWF applications. It has been a pet project of mine for some time, and I decided to share it with a broader audience.

Within my current role, I have to look at all aspects of SWF applications from cross-site scripting issues to binary analysis. Therefore, the tool includes capabilities to perform everything from testing cross-site scripting to viewing the individual SWF tags within the file format. I am hoping that by releasing the tool as an open-source ActionScript application, it will encourage all ActionScript developers to learn more about security. The tool is designed to be an extensible framework everyone can build upon or modify. More information on the tool can be found in my DevNet article.

In addition to demonstrating the tool, I will also be talking about Advanced Persistent Response. Adobe has been the focus of hackers for some time, and I plan to discuss what we have learned and observed in the process of responding to those threats. My talk will be on Wednesday at 3:30pm, if you are interested. When I am not speaking, you can probably find me and the Adobe team either at the Adobe table or milling around the pwn2own contest for no particular reason. Please feel free to come by and talk with us. See you there!

When Do I Need to Apply This Update – Adding Priority Ratings to Adobe Security Bulletins

How urgently do I need to apply this update? That’s the most common question we get from customers in managed environments when we release a security bulletin. Our current severity ratings do a good job of objectively describing the worst-case scenario involved with a security issue, but they do not necessarily tell a customer all they need to know about the risk and priority of a particular security update. All critical security updates are not created equal. For example, if a Flash Player issue is being exploited in the wild, the update to resolve the vulnerability deserves a much higher priority than, say, a patch for a critical vulnerability in Photoshop. After all, Flash Player is a browser-based plugin with hundreds of millions of customers. Photoshop, on the other hand, has a much smaller customer base and would require significant social engineering to successfully exploit the product. So we started to wonder, how can we communicate the priority of our security updates more effectively?

We want to be as simple and direct as possible about the real-world risk associated with the vulnerabilities addressed in any given security update, and we decided that adopting a separate priority ranking scheme was the best way to accomplish this. Here is the priority scheme we are planning to use to rank security updates in the future:

Priority 1 Priority 2 Priority 3
This update resolves vulnerabilities being targeted, or which have a higher risk of being targeted, by exploit(s) in the wild for a given product version and platform. Adobe recommends administrators install the update as soon as possible. (for instance, within 72 hours). This update resolves vulnerabilities in a product that has historically been at elevated risk. There are currently no known exploits. Based on previous experience, we do not anticipate exploits are imminent. As a best practice, Adobe recommends administrators install the update soon (for instance, within 30 days). This update resolves vulnerabilities in a product that has historically not been a target for attackers. Adobe recommends administrators install the update at their discretion.

We’re going to base our priority ranking on historical attack patterns for the relevant product, the type of vulnerability, the platform(s) affected, and any potential mitigations that may be in place. This is a new system, so we may find that adjustments will need to be made. We also believe that continuing to use the current severity ratings makes sense, since this information has been helpful to many customers, so you can expect to see both ratings being used in future security bulletins.

We look forward to your feedback. Our goal is to help our customers in managed environments prioritize updates, so we’ll see if this new priority ranking scheme works to accomplish that! As we have been emphasizing a lot recently, the majority of attacks we are seeing are exploiting software installations that are not up-to-date with the latest security updates, so as always we recommend that users keep their software installations updated with the latest version of Adobe software.

Buzz from Kaspersky SAS 2012

Hello world! Karthik here from Adobe Product Security Incident Response Team (PSIRT) engineering. Last week, I got to attend the Kaspersky Security Analyst Summit 2012 in Cancun, which was a melting pot of great security research and ideas. It was wonderful to meet researchers from industry and government and discuss Adobe’s security activities, such as product security incident response and product vulnerability sharing in the Microsoft Active Protections Program (MAPP). Thanks for listening and sharing your ideas. Let’s keep the conversation going.

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.’”

SAS 2012 Security Jeopardy Winners

Until the next conference!

Karthik

Flash Player Sandboxing is Coming to Firefox

Peleus here. In December of 2010, I wrote a blog post describing the first steps towards sandboxing Flash Player within Google Chrome. In the blog, I stated that the Flash Player team would explore bringing sandboxing technology to other browsers. We then spent 2011 buried deep within Adobe laying the groundwork for several new security innovations.

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!

Adobe Reader and Acrobat X (10.1.2) and 9.5 Add JavaScript Whitelisting Capability

Today, we released the quarterly security updates for Adobe Reader and Acrobat (versions 10.1.2 and 9.5). The security bulletin and release notes have comprehensive details. This blog post will highlight an important security-related enhancement in this release:

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)

Flash Player 11 Privacy and Security Updates

You may have seen our Flash Player 11 announcement earlier today. In addition to the major advancements for gaming, media and data-driven applications, this new version of Flash Player, which will be available in early October, will include several important new privacy and security features. We’ll start with privacy:

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

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!

Cheers

Steve “Capn Steve” Adegbite

Reflecting on RECON2011:

Last week I got a chance to travel to Montreal to attend the RECON2011 conference. In my last blog post I talked about this conference being among the best for deep technical security information. I am glad to report that’s still the case. There were talks on all aspects of reverse engineering, multiple operating system internals, and other complex security topics.The conference is run as one track, packed with technical presentations on relevant security topics.  This is a great plus for our security staff that are always continuously looking to improve Adobe products security.   

 The other plus is that the number of technical experts in one room creates a great opportunity for us to engage in valuable security-related conversations. Here at Adobe, listening to the feedback and input from the security community is a critical aspect of our overall security strategy. We are always eager to hear people’s thoughts on the strengths and weaknesses of our efforts.  At RECON2011, we had the opportunity to talk with many in the security community about our activities, and I am happy to say that most seemed to feel that we are on the right track but are not done yet.  This is something we recognize.  We understand that security is more like a marathon versus a sprint. So there is always more good work that can be done, especially as the threat landscape is constantly evolving. This conference allowed us to collect some great feedback and we will we be bringing that feedback in-house to evaluate and put to use.  One example of a valuable piece of feedback was to continue to innovate on our sandbox initiative. Sandbox has been great for the Reader 10 user base and continual improvement can only make things better.

 

Until next time,

 Steve “Capn Steve” Adegbite