Posts tagged "security"

RSA Conference Schedule

Brad Arkin here. RSA Conference is upon us once again. There are some exciting talks and events on the calendar, but I’m looking forward to the informal “hallway track” the most.

In the days leading up to RSA Conference, everyone in the industry seems to be reminding each other of the sessions you “absolutely should not miss.” Here’s my pitch—and a summary of where you can find me and members of the Adobe Secure Software Engineering Team at RSA Conference:

MONDAY, FEBRUARY 27, 2012

On Monday, February 27, you’ll find me at the “Improving Application Security Seminar” (SEM-002), along with experts from Symantec, Cigital, Fortify Software, HP, Microsoft, and Veracode. This full-day seminar for delegates will kick off at 8:30 a.m. in Room 305 at the Moscone Center.

In the evening, please join the Adobe Security Team from 6:30 to 9:30 p.m. at Roe Restaurant (10 Hawthorne Street, two blocks from the Moscone Center) for food, drinks, and a lively discussion on the current challenges facing the security industry. Please note that this is a limited capacity event, so please register for this event as soon as possible to save your spot.

TUESDAY, FEBRUARY 28, 2012

Join Adobe’s Kyle Randolph and other participants from EMC, Cigital, Symantec and Microsoft for a panel discussion titled “Making Sense of Software Security Advice: Best vs. Practiced Practices” (ASEC-106) at 1:10 p.m. on Tuesday, February 28, in Room 302. The panel, moderated by EMC’s Reeny Sondhi, will help you make sense of the different software security advice available and discuss how to apply it to your work.

WEDNESDAY, FEBRUARY 29, 2012

If you are an early riser, join me at 8:00 a.m. on Wednesday, February 29, in Room 302 for a panel discussion moderated by Chenxi Wang from Forrester, titled “War Stories: The Good, Bad and the Ugly of Application Security Programs” (ASEC-201). I’ll be participating on the panel along with Doug Cavit from Microsoft and James Routh from JPMorgan Chase & Co. We look forward to your questions and comments!

Afterwards, don’t miss my talk “Never Waste a Crisis – Necessity Drives Software Security Improvements” (ASEC-203), which will take place from 10:40-11:30 a.m. in Room 302. I’ll share some general lessons on both how to prepare for a crisis and what to do once it arrives. And I’ll provide step-by-step instruction on what to do through every phase of a crisis with an eye towards promoting the priority of software security activities throughout.

THURSDAY, MARCH 1, 2012

On Thursday, March 1, I’ll be moderating a SAFECode panel discussion titled “What Motivated My Company to Invest in a Secure Development Program?” (ASEC-301). Other panelists include Steven Lipner from Microsoft, Gunter Bitz from SAP, Janne Uusilehto from Nokia, and Gary Phillips from Symantec. Don’t miss what promises to be a lively discussion from 8:00-9:10 a.m. in Room 302!

We hope to see you at RSA Conference!

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)

Adobe Welcomes Siemens to SAFECode!

I’m excited to welcome Siemens as the newest member of SAFECode and Dr. Frances Paulisch to the SAFECode board of directors.

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.

Notes from RSA Conference Europe 2011

Brad Arkin here, live from RSA Conference Europe 2011, which opened earlier today in London. I’m moderating a panel on Thursday, October 13, 2011, titled “Building Secure Software—Real World Software Development Programs” (ASEC-302). If you happen to be at the show, please drop by King’s Suite A (West Wing) at the Hilton London Metropole Hotel at 10 a.m. to join me and my SAFECode peers (Steve Lipner from Microsoft, Gunter Blitz from SAP, Reeny Sondhi from EMC, and Janne Uusilehto from Nokia) as we discuss our experiences of putting together secure development programs. Also, Bryan Sullivan is presenting “NoSQL, But Even Less Security: Attacking and Defending NoSQL Databases” (DAS-207) on Wednesday, October 12, 2011 at 2:10 p.m. (A podcast introducing Bryan’s talk is available 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.

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

Inside Adobe Reader Protected Mode – Part 1 – Design

Introduction

Kyle Randolph here, along with the security team for the Acrobat family of products, including Adobe Reader. This is the first post in a multi-part series about the new sandboxing technology used in the Adobe Reader Protected Mode feature that was announced back in July. We will take a technical tour of the sandbox architecture and look at how its different components operate and communicate in ways that will help contain malicious code execution. 

What is sandboxing?

sandbox is a security mechanism used to run an application in a confined execution environment in which certain functions (such as installing or deleting files, or modifying system information) are prohibited. In Adobe Reader, “sandboxing” (also known as “Protected Mode”) adds an additional layer of defense by containing malicious code inside PDF files within the Adobe Reader sandbox and preventing elevated privilege execution on the user’s system. 

The Adobe Reader sandbox leverages the operating system’s security controls to constrain processes execution to the principle of least privilege. Thus, processes that could be subject to an attacker’s control run with limited capabilities and must perform actions such as accessing files through a separate, trusted process. This design has three primary effects:

  • All PDF processing such as PDF and image parsing, JavaScript execution, font rendering, and 3D rendering happens in the sandbox.
  • Processes that need to perform some action outside the sandbox boundary must do so through a trusted proxy called a “broker process.”
  • The sandbox creates a new distinction of two security principals: the user principal, which is the context in which the user’s logon session runs, and the PDF principal, which is the isolated process that parses and renders the PDF. This distinction is established by a trust boundary at the process level between the sandbox process and the rest of the user’s logon session and the operating system.

The goal of this design aspect is to process all potentially malicious data in the restricted context of the PDF principal and not in the context of the fully privileged user principal. As shown in the diagram below, Inter-process communication (IPC) is used when the sandbox needs an action performed by the broker as the user principal instead of the PDF principal, such as calling an OS API or getting write access to a file.

Sandboxing is relatively new for most enterprise applications because it is difficult to implement in mature software (i.e. software with millions of lines of code) that is already deployed across a virtually limitless number of environments. A few recently shipped products that demonstrate the sandboxing proof of concept include Microsoft Office 2007 MOICE, Google Chrome, and Office 2010 Protected View. The challenge is to enable sandboxing while keeping user workflows functional without turning off features users depend on. The ultimate goal is to proactively provide a high level of protection which supplements the mitigation of finding and fixing individual bugs.

Design Principles

The sandbox was designed with several security best practices in mind:

  • Leverage the existing operating system security architecture: The Adobe Reader sandbox relies on Windows operating system security features such as restricted tokens, job objects and low integrity levels.
  • Leverage existing implementations: The Adobe Reader sandbox builds on the Google Chrome sandbox and also took Microsoft Office 2010 Protected Mode into consideration.
  • Adhere to the principle of least privilege: Every process (executable code) can only access the resources necessary to perform its legitimate purpose.
  • Consider all sandbox data untrusted: Assume all data communicated out of the sandbox is potentially malicious until it has been validated. 

 
Mitigations Provided by the Reader Sandbox

For the sake of this discussion, let’s assume that an attacker has achieved arbitrary code execution by exploiting an unpatched vulnerability in the Adobe Reader renderer and is able to convince the user to click on a malicious PDF file delivered via an e-mail attachment or to click on a link to a malicious PDF file hosted on a website controlled by the attacker. Historically, just double-clicking and rendering this PDF file could lead to total compromise of the user’s machine. Say, for example, the attacker knows and is able to exploit an unpatched buffer overflow vulnerability in the Adobe Reader JavaScript APIs or an integer overflow vulnerability in the Fonts components. Once that’s done, it’s fairly trivial for the attacker to lure victims into opening the weaponized PDF file by deploying it via a spam e-mail/advertisement or hosting it on a popular website.

In-scope goals: Adobe Reader’s sandboxing architecture primarily focuses on preventing the attacker from doing two things:

  1. Installing malware on the user’s machine
  2. Monitoring the user’s keystrokes when the user interacts with another program

If the attacker succeeds in circumventing the above mentioned in-scope goals, then he or she can cause serious damage to the user. For example, once the attacker is able to install malicious software on the user’s computer, he or she could end up having write/update/delete access to the file system and registry and might attempt to install a botnet client that receives commands over the network and engages in coordinated attacks across the network. In the other scenario where the attacker is able to monitor the user’s keystrokes, he or she can attempt to steal confidential and sensitive information, such as passwords and credit card numbers.

So simply put, the Adobe Reader sandbox–much like the Google Chrome Sandbox–does not allow the attacker to install persistent malware or tamper with the user’s file system and thwarts the attacker from taking control of the user’s machine. This ties back to the design principle of least privilege: an exploit can possibly run within the application but cannot do anything malicious to the user’s machine because its access is completely blocked by the highly restrictive sandbox environment. In conclusion, this greatly reduces the attack surface of the Adobe Reader software application.

Limitations

The sandbox’s reliance on the operating system means that it could potentially be subject to its flaws. Like the Google Chrome sandbox, the Adobe Reader Protected Mode sandbox leverages the Windows security model and the operating system security it provides. This intrinsic dependency means the sandbox cannot protect against weakness or bugs in the operating system itself. However, it can limit the severity of such flaws when code executes inside the sandbox, since the sandbox blocks many common attack vectors.

Our first version of sandboxing is not designed to protect against:

Unauthorized read access to the file system or registry. We plan to address this in a future release.

Network access. We are investigating ways to restrict network access in the future.

Reading and writing to the Clipboard

Insecure operating system configuration

The last ingredient for a Windows sandbox according to the Practical Windows Sandboxing recipe is to use a separate desktop for rendering the user interface (UI). We chose not to use a separate desktop due to the complexity of the change in how Adobe Reader renders its UI. Instead, we enumerated the attack vectors that sharing a desktop leads to, shatter attacks and SetWindowsHookEx DLL Injection attacks. These attack vectors were mitigated through alternative means, using low integrity and limits in the sandbox job object, which will be discussed in more detail in our next post.

Conclusion

This concludes the overview of the Adobe Reader Protected Mode sandbox architecture and limitations. In future posts, we will explore the sandbox process and the broker process in more detail, as well as their inter-process communication (IPC) mechanisms. Finally, we will comment on the security testing we use to validate the security of the Adobe Reader sandbox.

-Liz McQuarrie, Ashutosh Mehra, Suchit Mishra, Kyle Randolph, and Ben Rogers

Now Live on Adobe TV: Members of Adobe’s Security Solutions Team!

Well, you’ve experienced us in print…now see us in these exciting, new moving pictures! Listen to John Landwehr and John B Harris discuss Adobe’s key information assurance capabilities and how they can help you achieve content-centric security with products that provide integrity, confidentiality, authentication and privacy.

Black Hat Europe

Kyle Randolph here. I will be attending Black Hat Europe this week as part of ASSET’s security community outreach effects. If you are interested in discussing Adobe security, please shoot me an email (krand at adobe dot com) and we can meet up. Looking forward to discussing application security with other folks in the security community this week!

A Few Words on the January 2010 Security Update for Adobe Reader and Acrobat

Kyle Randolph here. I work closely with the Adobe Reader and Acrobat engineering team as we continue to work hard on the security initiative first announced back in May 2009. Today, the team announced new security improvements in Adobe Reader and Acrobat 9.3 and 8.2. This is the third quarterly security update for Adobe Reader and Acrobat and we are starting to roll out to users the configuration options and features that we began designing last summer to mitigate the evolving security threats we were seeing. Let me explain the security geek coolness factor of the improvements in this release as well as the improvements in the October quarterly security update.
New Adobe Reader Updater / Acrobat Updater
We introduced the new updater in the October Adobe Reader and Acrobat 9.2 and 8.1.7 update as beta technology, and today, we are testing the new technology with a real-world security update to users participating in the beta program. (Since we are still conducting the pilot, only users who are participating in the beta program are receiving today’s update via the new updater.) The new updater improves the user experience and helps users stay up to date with the new option of receiving security updates automatically, via background updates, which have been shown to have better patch adoption. Some customers, such as corporate IT administrators, need to know and manage which updates are installed and when. But a lot of customers, particularly consumers and individuals who don’t have the autopilot luxury of a managed desktop environment, just want to have the most secure and up-to-date version, and don’t want to be interrupted when it is time to install an update. By allowing customers to select an update process that automatically runs in the background, we can help protect more users from attacks against known, patched vulnerabilities.
JavaScript Blacklist Framework
Over the past two years, a significant number of external vulnerabilities found in Adobe Reader and Acrobat have been in JavaScript. The Adobe Reader and Acrobat engineering team has been busy creating new ways to help protect against this attack vector. The new Adobe Reader and Acrobat JavaScript Blacklist Framework, which was added with the October update, is great for security because it provides a method to disable a specific vulnerable API instead of disabling JavaScript completely. This allows Adobe Reader to be configured in a way that is not vulnerable if a 0-day vulnerability that exploits a JavaScript API is identified. Better still, the new blacklist is stored in the registry and can be configured centrally in enterprise environments using Group Policy Objects (GPO) to prevent end users from overriding it. As an example, the recent vulnerability CVE-2009-4324 could be mitigated by blocking the DocMedia.newPlayer API.
For more info on the JavaScript Blacklist Framework, check out http://kb2.adobe.com/cps/504/cpsid_50431.html.
Yellow Message Bar
The Yellow Message Bar was added in the October security update for Adobe Reader and Acrobat (9.2 and 8.1.7), but it is cool enough to mention here. This makes the user experience much more pleasant when a dangerous API is selectively blocked by the JavaScript Blacklist Framework or due to the Enhanced Security configuration. Previously, you’d get a modal dialog box asking users if they would like to re-enable some unsafe behavior, as shown in the screen shot below:
js_modal_warning.jpeg
Now the Yellow Message Bar appears at the top of the document as shown below:
js_yellowbar.png
Since the Yellow Message Bar stays out of the way, it enables users to interact with the PDF without exposure to a disabled feature’s security risk, if you don’t need that functionality. Additionally, the choices are more granular in that the Yellow Message Bar decision is to trust a document one time or always, as opposed to a decision to turn the entire feature back on for all documents. These changes should reduce the frequency and impact of accidental click-throughs or users getting into the habit of clicking through warnings without reading them, which can lead to social engineering and phishing attacks. This same type of change in security notification has been adopted in other vendors’ desktop products, such as Microsoft Office, as a security best practice. The Yellow Message Bar will appear when an action is blocked by Enhanced Security in Adobe Reader or Acrobat or by the JavaScript Blacklist Framework.
For more info on the Yellow Message Bar, see http://kb2.adobe.com/cps/504/cpsid_50432.html.
Multimedia (Legacy) off by Default
Another effective technique to reduce security risk for our customers is to reduce the attack surface of the product. Legacy multimedia is a set of rarely used features which have a broad attack surface. The Multimedia (Legacy) features are no longer trusted by default. Users that open PDFs that contain legacy multimedia will see a Yellow Message Bar at the top of the document.
Conclusion
This January update for Adobe Reader and Acrobat builds on the good work put into the October release to continue increasing the security protection for our customers with each quarterly security release in addition to fixing externally reported vulnerabilities. We’re excited to evaluate the results for the pilot of the new Adobe Reader Updater with its automatic mode for background updates. The Yellow Message Bar notifications provide an improved user interface to help protect users. And we’re providing more fine-grained control for any future JavaScript API vulnerabilities with the JavaScript Blacklist Framework. Finally, disabling Legacy Multimedia by default protects users against any potential security vulnerabilities identified in these rarely used features.