Search Results for "sandbox"

Training Secure Software Engineers, Part 1

Ninja Button Black 1in.jpegOverview

You may have seen our previous post about the release of SAFEcode’s Software Security Training, to which Adobe contributed content from our ASSET Software Security Certification Program. This is the first of a three part series of posts about the ASSET  training. It’s our hope that people who want to supplement the SAFEcode training, or build their own training, might benefit from hearing about our experience building our program. In this post, I’ll provide an overview of  the certification program which is a key part of the Adobe Secure Product Lifecycle (SPLC). In future posts, I’ll present the logistics of building your own security training program or supplementing the SAFECode training; using metrics to track your progress; and some tips for success based on lessons we learned along the way.

In early 2009, the ASSET team looked around for pre-existing security training for developers and quality engineers and while we found plenty of content out there, nothing suited our specific needs. As a result, we decided to develop the Adobe Software Security Certification Program to begin teaching our developers, quality engineers and managers the basic, common language of security. Since then, Adobe has gone from being nominated for the “Lamest Vendor Response” at the 2008 Black Hat Pwnie Awards, to implementing the Adobe Reader Protected Mode (sandbox), the Flash Player Protected Mode (sandbox) and drastically decreasing our zero-day exploits and response time.

We believe the ASSET Software Security Certification Program has helped change employee attitudes toward security. This in turn has influenced the way software is developed and how reported issues are fixed. The training program has enabled the Adobe Software Security Engineering Team (ASSET) to transition from educating development teams on primary security concepts to the ability to have more in-depth, fluent conversations regarding security.

The Basics
At the basic level, the ASSET Certification Program is a four-tiered system, where people can earn a “belt” per level attained: white, green, brown and black.

The first two levels, the white and green belts, consist entirely of computer-based trainings (CBTs). The last two levels, the brown and black belts, are purely experiential. As expected, there are a lot more white belts within the company than there are black belts. While every developer needs to know something about security, not every developer needs to specialize in it. We provide an opportunity and a path for people who want to be security leaders, while at the same time providing a foundation for everyone to understand security fundamentals.

While it takes about eight hours of computer-based training to achieve a white belt, it can take hundreds of hours of hands-on project work to earn a brown or black belt. Some projects that can help aspiring brown and black belt candidates earn points toward their goal include: speaking at security conferences, implementing testing strategies, architecting or re-architecting products or components to enhance their security, or creating vulnerability detection and response strategies. Often these projects are combined.

Product teams and managers set goals to have all their employees white or green belt certified by a certain date. Motivated individuals make higher-level belts a part of their annual objectives and gain increased visibility and recognition when they achieve those levels. Another great benefit for those that earn higher-level belt status is they become candidates for the embedded “security champion” role within their team. ASSET leverages these champions and they are a critical part of how Adobe implements our Secure Product Lifecycle.

Birth of the Ninja
Along the way, we created an identity and corresponding mascot for the program – the ASSET Ninja – as a way for people to connect with their achievement. We informally refer to those who achieve certification as Ninjas. There are Ninja pins and digital Ninja badges for people to display. Ninjas have special skills. Ninjas are cool.

In the next post, I’ll talk about the logistics of creating your own certification program or supplemental security training, and tracking your progress.

Josh Kebbel-Wyen
Sr. Program Manager

 

The Evolution of Exploit Sophistication

When we look at the exploits that Adobe patched from February and March of this year, it is clear that today’s zero-day exploits are increasingly more sophisticated. This increase in sophistication is not limited to the skills needed to find and exploit the vulnerability. The code used to exploit the environment is also more robust in terms of code quality and testing. In short, exploit creation today requires the same level of rigor as professional software engineering projects.

Today’s advanced exploits need to be written to work in any target environment. For instance, February’s Reader 0-day supported 10 different versions of Reader with 2 sub-versions dependent on the end-user’s language. In addition, Flash Player CVE-2013-0634 had shell code for Windows XP, Vista, Windows 7, Server 2003, Server 2003 R2, Server 2008 and Server 2008 R2 as well as supporting six versions of Flash Player. Variants of CVE-2013-0634 also supported Firefox and Safari on Mac OS X. An exploit developer would need a robust testing environment to ensure that the exploit would work in that many different environments for each version of Flash Player. The exploit writers even took into account different CPU architectures by including a signed 32-bit payload and a 64-bit payload. This reflects the fact that these exploits are written with professional code quality and stability requirements for distribution across a dynamic target base.

As vendors are increasing software defenses through techniques such as sandboxing, attackers are now combining multiple vulnerabilities from different vendors to achieve their goals.When I look at the reports from Pwn2Own and some of the recent zero-day reports such as CVE-2013-0643, attacks are moving toward combining vulnerabilities from multiple products, some of which are from different vendors. We are moving away from the model of single vulnerability exploits.

This is all a part of the natural evolution of the threat landscape and the commercialization of exploits. This will require an equal evolution on the part of vendors in their software defences. Karthik Raman and I will be discussing this topic, “Security Response in the Age of Mass Customized Attacks,” in more detail at the upcoming Hack in the Box Conference (HITB) Amsterdam next week. Please stop by our talk if you would like to discuss this further.

Peleus Uhley
Platform Security Strategist

Top 10 Web Hacking Techniques of 2012

I was honored that Jeremiah Grossman asked me to serve again on the panel for the Top 10 Web Hacking Techniques of 2012. During the process, I get to take a look at the year’s most interesting research in greater detail than what is normally allowed in my day-to-day schedule. It makes me question what I thought I knew about existing attack techniques and how this year’s top research reflects on the industry.

Ranking the entries is challenging when you are comparing an SSL cryptography bug vs. the server side request forgery attacks vs. attacks against Chrome add-ons. To do so, requires that you read the full research, review the source code that was written and try to determine what impact the research had on the community. I typically start by considering factors such as:

  • Is the research completely new or is it just an incremental improvement of a known issue?
  • How many end-users are impacted?
  • Is this an individual bug affecting one vendor or an industry-wide issue?
  • What does successful exploitation yield (XSS, file access, OS control, etc.)?
  • Is the exploit practical to conduct?
  • What was the depth of research (a white paper, a tool, etc.)?
  • Extra points for style or creativity?

Reviewing the research to this depth then leads to uncovering smaller bits that are interesting in their own right. For instance, the Blended Threats and JavaScript research leveraged HTML5 to create cross-site file upload capabilities. You will find links to tools that back up the research in entries such as Blended Threats, Attacking OData, Bruteforcing PHPSESSID, and the Chrome add-on research. In some cases, the research reminds you about how many of the old tricks can be re-purposed against new technologies.

As an example, in July, 1998 Microsoft issued security bulletin MS98-004 which allowed, “Unauthorized ODBC Data Access with RDS and IIS”. In 1999, new information was published regarding the bug and Bugtraq ID 529 said exploiting the vulnerability could result in, “obtaining access to non-public servers or effectively masking the source of an attack on another network”. Today, we would classify this type of attack as, “Server Side Request Forgery” (SSRF). Modern SSRF attacks can include both old and new attack techniques. For instance, the ERPScan paper discussed how to use the gopher: protocol in an XML External Entity to attack SAP gateways. Over a decade later, we now have a formal taxonomy for classifying these types of bugs. However, the core issue of effectively sandboxing a web application to a finite set of resources is not much easier than it was 15 years ago. If anything, it has become more difficult as the number of supported communication channels between endpoints has increased.

Finally, you begin to think about why these top 10 bugs are critical to the industry. The panel ranked,”Compression Ratio Info-leak Made Easy” (CRIME) in the top slot due to the overall difficulty of the research, the vendor action required to address it, and the importance of SSL to the security ecosystem. As we move more data to the cloud where we will access it via our mobile or tablet devices, we will increasingly rely on SSL to protect it in transmission. Another interesting trend in this year’s top list was the multiple SSRF entries. As I mentioned, it wasn’t a completely new concept but rather a concept that is seeing a renewed interest as more data moves to the cloud. There were three SSRF entries in the Top 15 and the SSRF entry that was ranked number 2 includes research by two separate groups. As our dependence on cloud storage grows, SSRF will become an increasingly used attack vector for reaching all the critical data that lies behind those front end cloud servers.

As everyone reviews the Top 15, I encourage you to find time to read through each entry. The final list represents great information by talented researchers. Also, I would recommend sharing the list with your engineers. When I shared the Top 15 list with our internal Adobe community a few months ago, I can attest that at least one developer recognized a flaw that existed in his system and corrected the issue. Thanks to Jeremiah Grossman for putting this together each year and allowing me to be a part of it.

Peleus Uhley
Platform Security Strategist

Raising the Bar for Attackers Targeting Flash Player via Office Files

Adobe has worked hard to make Flash Player more secure. We have worked with our partners Google and Mozilla to sandbox Flash Player in Google Chrome  on Windows, Mac, Linux and Chrome OS, and in MozillaFirefox on Windows. We have also been working closely with Microsoft to deliver Flash Player with Internet Explorer 10 on Windows 8, which means Flash Player runs in Enhanced Protected Mode, further restricting the plugin’s privileges in the browser, and Flash Player updates are delivered through Windows Update. (I’ll be blogging on the protections Enhanced Protected Mode provides for Flash Player users in a separate blog post later this month.) We also welcomed Apple’s initiative to  encourage Mac users to stay up-to-date by disabling older versions of Flash Player and directing users to install the latest, most secure version of Flash Player, and Mozilla’s click-to-play feature in Firefox. And we have worked hard on improving the update mechanism in Flash Player to make it easier for our user s to stay up-to-date. Windows and Macintosh users receive critical security patches through regular update checks by the Flash Player update mechanism. These enhancements help to protect users as they browse the Web.

Over the last year, Adobe has been driving down the number of Flash (SWF)-based zero-days used in the wild. Since the introduction of Adobe Reader X Protected Mode (aka sandboxing) in November 2010, the most common Flash Player zero-day attack vector has been malicious Flash content embedded in Microsoft Office documents and delivered via email. In fact, today’s Flash Player update addresses CVE-2013-0633 and CVE-2013-0634, both of which are being exploited in targeted attacks leveraging this very attack vector. In the next feature release of Flash Player, which is currently in beta, we will be delivering a solution designed to help make this attack vector less attractive.

Microsoft Office 2010 includes a Protected Mode sandbox for limiting the privileges of content within the document. If the document originates from the Internet or Untrusted Zone, the Protected View feature will prevent Flash Player content from executing by default. However, not everyone has the ability to update to Office 2010. In Office 2008 and earlier, Flash Player content will run by default without sandbox protections, making it an attractive attack vector for targeted attacks.

To protect users of Office 2008 and earlier, the upcoming release of Flash Player will determine whether Flash Player is being launched within Microsoft Office and check the version of Office. If Flash Player is launched within a version prior to Office 2010, Flash Player will prompt the end-user before executing the Flash content with the dialogue below:

OfficeClickToPlayFP

Therefore, if an end-user opens a document containing malicious Flash content, the malicious content will not immediately execute and impact the end-user. This extra step requires attackers to integrate a new level of social engineering that was previously not required.

We’ve seen these types of user interface changes lead to shifts in attacker behavior in the past and are hopeful this new capability will be successful in better protecting Flash Player users from attackers leveraging this particular attack vector as well.

We’ll post an update here as soon as this new feature in Flash Player becomes available. Stay tuned!

Peleus Uhley, Platform Security Strategist, ASSET

New Security Capabilities in Adobe Reader and Acrobat XI Now Available!

This week, Adobe released the next generation of Adobe Reader XI and Acrobat XI with improved security features, among many other enhancements.

Adobe Reader X represented a milestone release in terms of security with the introduction of Adobe Reader Protected Mode (aka “sandboxing”), which created a more secure environment for our customers. We followed the Adobe Reader X release with the introduction of Adobe Acrobat X (10.1) Protected View. Since we added sandbox protection to Adobe Reader and Acrobat, we have not seen any exploits in the wild that break out of the Adobe Reader and Acrobat X sandbox.

Over the last year, we have continued to work on adding security capabilities to Adobe Reader and Acrobat, and today, we are very excited to present Adobe Reader and Acrobat XI with a number of new or enhanced security features.

Adobe Reader XI Protected Mode (Enhanced)

In our Adobe Reader X sandbox implementation, the sandboxing architecture’s primary focus was on “write protection” to prevent the attacker from installing malware on the user’s machine and from monitoring the user’s keystrokes when the user interacts with another program.

In Adobe Reader XI, we have added data theft prevention capabilities by extending the sandbox to restrict read-only activities to help protect against attackers seeking to read sensitive information on the user’s computer.

Adobe Reader Protected View (New) and Adobe Acrobat Protected View (Enhanced)

To provide an additional layer of defense and strengthen the sandbox protection in Adobe Reader and Acrobat even further, we have implemented a separate desktop and WinStation in Adobe Reader and Acrobat XI, which will block, for instance, screen scraping attacks. For additional insights into implementing a separate desktop to provide an additional layer of defense, see David LeBlanc’s Web log entry Practical Windows Sandboxing – Part 3. For details on WinStations and desktops in general, click here.

This mode effectively introduces a new Protected View in Adobe Reader and enhances the Protected View implementation in Adobe Acrobat even further. Protected View behaves identically for Adobe Reader and Acrobat, whether viewing PDF files in the standalone product or in the browser. For more information, administrators can refer to the Enterprise Toolkit for Acrobat Users.

Force ASLR Support in Adobe Reader/Acrobat XI

Adobe Reader and Acrobat leverage platform mitigations such as Data Execution Prevention (DEP), Address Space Layout Randomization (ASLR), etc. In Adobe Reader and Acrobat XI, we have enabled support for Force ASLR on Windows 7 and Windows 8. Force ASLR improves the effectiveness of existing ASLR implementations by ensuring that all DLLs loaded by Adobe Reader or Acrobat XI, including legacy DLLs without ASLR enabled, are randomized. By enabling Force ASLR in Adobe Reader and Acrobat XI, we are making it even more difficult for an attacker to exploit vulnerabilities. For more information on ASLR and Force ASLR, please refer to Microsoft’s Knowledge Base article on the topic.

PDF Whitelisting Framework

For high-assurance, managed enterprise environments, we’ve added the Adobe PDF Whitelisting Framework, which allows administrators to selectively enable advanced functionality, such as JavaScript for specific PDF files, sites or hosts, on both Windows and Mac OS.

Support for Elliptic Curve Cryptography

And last but not least, we have added support for Elliptic Curve Cryptography (ECC) for digital signatures in the area of content security. Users can now embed long-term validation information automatically when using certificate signatures and use certificate signatures that support elliptic curve cryptography (ECC)-based credentials.

We’re excited about these additional security capabilities in Adobe Reader and Acrobat XI, which mark the latest in our continued endeavor to help protect our customers by providing a safer working environment.

Priyank Choudhury
Security Researcher, Adobe Secure Software Engineering Team (ASSET)

Inside Flash Player Protected Mode for Firefox

Today, we launched Flash Player Protected Mode for Firefox on Windows. Our Protected Mode implementation allows Flash Player to run as a low integrity process with several additional restrictions that prohibit the runtime from accessing sensitive resources. This approach is based on David LeBlanc’s Practical Windows Sandbox design and builds upon what Adobe created for the Adobe Reader X sandbox. By running the Flash Player as a restricted process, Adobe is making it more difficult for an attacker to turn a simple bug into a working exploit. This blog post will provide an overview of the technical implementation of the design.

When you first navigate to a page with Flash (SWF) content, you will notice that there are now three processes for Flash Player. This may seem odd at first, but there is a good reason for this approach. One of the goals for the design was to minimize the number of changes that were necessary in Firefox to support the sandbox. By keeping Flash Player and Firefox loosely coupled, both organizations can make changes to their respective code without the complexity of coordinating releases.

The first process under the Firefox instance is called “plugin-container.exe.” Firefox has run plugins in this separate process for quite some time, and we did not want to re-architect that implementation. With this design, the plugin container itself is only a thin shim that allows us to proxy NPAPI requests to the browser. We also use this process as our launching point for creating the broker process. Forking the broker as a separate process allows us to be independent of the browser and gives us the freedom to restrict the broker process in the future. From the broker process, we will launch the fully sandboxed process. The sandboxed process has significant restrictions applied to it. It is within the sandbox process that the Flash Player engine consumes and renders Web content.

The restrictions we apply to this sandboxed process come from the Windows OS. Windows Vista and Windows 7 provide the tools necessary to properly sandbox a process. For the Adobe Reader and Acrobat sandbox implementation introduced in 2010, Adobe spent significant engineering effort trying to approximate those same controls on Windows XP. Today, with Windows 8 just around the corner and Windows XP usage rapidly decreasing, it did not make sense for the Flash Player team to make that same engineering investment for Windows XP. Therefore, we’ve focused on making Protected Mode for Firefox available on Windows Vista and later.

For those operating systems, we take advantage of three major classes of controls:

The first control is that we run the sandboxed process at low integrity. By default, processes started by the user are executed at medium integrity. Running the process at a low integrity level prevents the process from writing to most areas of the user’s local profile and the registry which require a medium integrity level to access. This also allows us to take advantage of User Interface Privilege Isolation (UIPI) which prevents low integrity processes from sending windows messages to higher integrity processes.

The second class of controls applied to the sandboxed process is to restrict the capabilities of the access token. A process will inherit a list of available Security Identifiers (SIDs) from the user’s security profile. These SIDs represent the different OS groups to which the user belongs. The access token contains this list of SIDs along with a set of controls for those SIDs. The Windows OS will compare the SIDs in the access tokens to the group permissions of the target object (e.g a file) to determine if access is allowed. The Windows OS allows us to define how the process SIDs are used in that comparison.

In general, a sandboxed process will need to be able to access resources directly owned by the user. However, in most cases it is unlikely that the sandbox will need the extended set of resources available to the user via group permissions. As a concrete example, your company may have a contact list on a network share that is available to everyone within your “Employees” group. It isn’t your file but you can access it because you are in the “Employees” group for your company. The Flash Player sandbox process doesn’t need to be able to directly access that file.

We identified that our sandbox process will need to access OS resources using the following SIDs: BUILTIN\Users, Everyone, the User’s Logon SID, and NTAUTHORITY\INTERACTIVE. For any other SIDs that are inherited from the user, we set the deny-only attribute to prohibit the process from accessing the resource based solely on that SID. To continue the example of the contact list on the file share, the sandboxed process would not be able to access the contact list because the file is not owned by you and the deny-only attribute on the “Employees” group SID would prevent access using your group permission. Process privileges are also limited to only the SeChangeNotifyPrivilege, which is required for the process to be notified of file system changes and for certain APIs to work correctly. The graphic below shows the permissions applied to the sandboxed process.

The third control applied to the sandboxed process are job restrictions. As one example, we can prevent the sandboxed process from launching other processes by setting Active Processes to 1. We can also limit the sandbox’s ability to communicate with other processes by restricting access to USER Handles and Administrator Access. The USER Handles restriction complements UIPI by preventing the process from accessing user handles created by processes not associated with our job. Finally, we can limit the sandboxes ability to interfere with the OS by limiting access to System Parameters, Display Settings, Exit Windows and Desktop.

More information on job limits, privilege restrictions and UIPI can be found in Part 2 of Inside Adobe Reader Protected Mode.

Once you get past OS-provided controls, the next layer of defense is Flash Player broker controls.

The OS broker process runs at medium integrity and acts as a gatekeeper between the untrusted sandbox process and the operating system. The sandbox process must ask the OS broker process for access to sensitive resources that it may legitimately need. Some examples of resources that are managed by the broker include file system access, camera access, print access and clipboard access. For each resource request, the sandbox contains policies which define what can and cannot be accessed. For instance, the sandbox process can request file system access through the broker. However, the policy within the broker will limit access to the file system so that the sandbox can only write to a predetermined, specific set of file system paths. This prevents the sandbox from writing to arbitrary locations on the file system. As another example, the sandbox cannot launch applications directly. If Flash Player needs to launch the native control panel, the Flash Player engine must forward the request to the broker process. The broker will then handle the details of safely launching the native control panel. Access to other OS resources such as the camera are similarly controlled by the broker. This architecture ensures that the sandboxed process cannot directly access most parts of the operating system without that access first being verified by the broker.

Overall, the Flash Player sandbox process has been a journey of incremental improvements with each step bringing end-users a more secure environment. We started by supporting Protected Mode within Internet Explorer, which enabled Flash Player to run as a low integrity process with limited write capabilities. From there, we worked with Google on building the Chrome sandbox, which converted Flash Player to using a more robust broker implementation. This release of Flash Player Protected Mode for Firefox on Windows takes the Chrome implementation one step further by changing Flash Player to run with job limits on the process. With Flash Player Protected Mode being based on the same technology as Adobe Reader X, we are confident that this implementation will be a significant barrier and help prevent exploits via Flash Player for Firefox users. Going forward, we plan to continue to build on this infrastructure with more sandbox projects, such as our upcoming release of Flash Player for Chrome Pepper. As we combine these efforts with other efforts, such as the background updater, we are making it increasingly more difficult for Flash Player to be targeted for malicious purposes.

Peleus Uhley, Platform Security Strategist, ASSET
Rajesh Gwalani, Security Engineering Manager, Flash Runtime

Flash Player 11.3 delivers additional security capabilities for Mac and Firefox users

Today’s release of Flash Player 11.3 brings three important security improvements:

  • Flash Player Protected Mode (“sandboxing”) is now available for Firefox users on Windows.
  • For Mac users, this release will include the background updater for Mac OS X.
  • This release and all future Flash Player releases for Mac OS X will be signed with an Apple Developer ID, so that Flash Player can work with the new Gatekeeper technology for Mac OS X Mountain Lion (10.8).

Flash Player 11.3 brings the first production release of Flash Player Protected Mode for Firefox on Windows, which we first announced in February. This sandboxing technology is based on the same approach that is used within the Adobe Reader X Protected Mode sandbox. Flash Player Protected Mode for Firefox is another step in our efforts to raise the cost for attackers seeking to leverage a Flash Player bug in a working exploit that harms end-users. This approach has been very successful in protecting Adobe Reader X users, and we hope Flash Player Protected Mode will provide the same level of protection for Firefox users. For those interested in a more technical description of the sandbox, please see the blog post titled Inside Flash Player Protected Mode for Firefox authored by ASSET and the Flash Player team.

The background updater being delivered for Mac OS X uses the same design as the Flash Player updater on Windows. If the user chooses to accept background updates, then the Mac Launch Daemon will launch the background updater every hour to check for updates until it receives a response from the Adobe server. If the server responds that no update is available, the system will begin checking again 24 hours later. If a background update is available, the background updater can download and install the update without interrupting the end-user’s session with a prompt.

With Mac OS X Mountain Lion (10.8), Apple introduced a feature called “Gatekeeper,” which can help end-users distinguish trusted applications from potentially dangerous applications. Gatekeeper checks a developer’s unique Apple Developer ID to verify that an application is not known malware and that it hasn’t been tampered with. Starting with Flash Player 11.3, Adobe has started signing releases for Mac OS X using an Apple Developer ID certificate. Therefore, if the Gatekeeper setting is set to “Mac App Store and identified developers,” end-users will be able to install Flash Player without being blocked by Gatekeeper. If Gatekeeper blocks the installation of Flash Player with this setting, the end-user may have been subject to a phishing attack. That said, a reminder that Flash Player should only be downloaded from the www.adobe.com website.

Background on Security Bulletin APSB12-08

Today we released Security Bulletin APSB12-08 along with corresponding updates for Adobe Reader and Acrobat. We’d like to highlight a few changes we are making with today’s releases.

Rendering Flash (SWF) Content in Adobe Reader and Acrobat 9.5.1

First off, starting with the Adobe Reader and Acrobat 9.5.1 updates, Adobe Reader and Acrobat 9.x on Windows and Macintosh will use the Adobe Flash Player plugin version installed on the user’s system (rather than the Authplay component that ships with Adobe Reader and Acrobat) to render any Flash (SWF) content contained in PDF files. We added an Application Programming Interface (API) to both Adobe Reader/Acrobat and Flash Player to allow Adobe Reader/Acrobat to communicate directly with a Netscape Plugin Application Programming Interface (NPAPI) version of Flash Player installed on the user’s system. From a security perspective, this means that Adobe Reader/Acrobat 9.x users will no longer have to update Adobe Reader/Acrobat each time we make available an update for Flash Player. This will be particularly beneficial to customers in managed environments because fewer updates help reduce the overhead for IT administration.

If Adobe Reader or Acrobat 9.5.1 is installed on a system that does not have the NPAPI version of Flash Player installed and the user opens a PDF file that includes Flash (SWF) content, a dialog will prompt the user to download and install the latest Flash Player. (Browsers such as Firefox, Opera and Safari use the NPAPI version of Flash Player as opposed to the ActiveX version of Flash Player used by Internet Explorer. Chrome uses a bundled version of Flash Player, even if there is an NPAPI version of Flash Player installed on the system.)

We are currently working on integrating the same API into Adobe Reader and Acrobat X, and will follow up with another blog post once this functionality is available in version X.

Rendering 3D Content in PDF Files

We also changed the default behavior in Adobe Reader and Acrobat 9.5.1 to disable the rendering of 3D content. Since the majority of consumers do not typically open PDF files that include 3D content and 3D content in untrusted documents has been a previous vector of attack we have disabled this functionality by default starting with version 9.5.1. Users have the option to enable 3D content, but a Yellow Message Bar will flag potentially harmful documents in the event that untrusted documents attempt to render 3D content. IT administrators in managed environments will also have the option of turning this behavior off for trusted documents.

More information on the two changes to content rendering described above is available in the Adobe Reader and Acrobat 9.5.1 release notes.

Further Alignment of the Adobe Reader/Acrobat Update Cycle with Microsoft’s Model

In June 2009, we shipped our first quarterly security update for Adobe Reader and Acrobat. Since then, we have come a long way in putting mitigations into place that make Adobe Reader and Acrobat a less attractive attack target. Sandboxing Adobe Reader and Acrobat X, in particular, has led to greater than expected results. Attackers have indicated through their target selection thus far that the extra effort required to attack version X is not currently worth it. Additionally, we have seen a lower volume of vulnerability reports overall against Adobe Reader and Adobe Acrobat. Given the shift in the threat landscape and the lower volume of vulnerability reports, we have revisited the decision to follow a strict quarterly release cycle.

After three years of shipping a security update once a quarter and announcing the date of the next update the same day we ship the current update, we are making a change. We are shifting to a model that more closely aligns with the familiar “Microsoft Patch Tuesday” cadence. We will continue to publish a prenotification three business days before we release a security update to Adobe Reader and Acrobat. We will continue to publish security updates on the second Tuesday of the month. We will continue to be flexible and respond “out of cycle” to urgent needs such as a zero-day attack. What we are discontinuing is the quarterly cadence and the pre-announcement of the next scheduled release date in the security bulletin for the previous release. We will publish updates to Adobe Reader and Acrobat as needed throughout the year to best address customer requirements and keep all of our users safe.

A Note on the Update Priority Ratings in APSB12-08

Finally, in today’s Security Bulletin, we rated Adobe Reader and Acrobat 9.5.1 for Windows as a “Priority 1″ update, while Adobe Reader and Acrobat X (10.1.2) was rated a “Priority 2″ update. This was an interesting decision, and we thought we would provide some background information: Although there are no exploits in the wild targeting any of the vulnerabilities addressed in Adobe Reader 9.5.1, Adobe Reader 9.x continues to be a target for attackers, so, for users who can not update to Adobe Reader X, we feel that urgently updating Adobe Reader 9.x remains a must to stay ahead of potential attacks.

Since the release of Adobe Reader X, Protected Mode mitigations (or the Protected View mitigations in Adobe Acrobat X version 10.1 and later) continue to be the best way to block potentially malicious behavior in PDF files. Therefore, a “Priority 2″ designation is appropriate for the Adobe Reader X and Acrobat X 10.1.2 updates. Adobe Reader and Acrobat for Macintosh and Linux have not historically been a target of attacks, and therefore are also assigned a “Priority 2.”

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

 

Adobe Acrobat and Reader 10.1 Released, Feature New Security and Signature Enhancements

Just last night, we announced the availability of updates to both Adobe Acrobat and Reader, bringing them up to version 10.1.  Along with a significant list of vulnerability mitigations, these updates also bring with them substantial changes to the secure operation of Acrobat on Windows, and to the digital signature functionality across platforms.

First, Acrobat 10.1 on Windows now features the same Protected Mode operation as Adobe Reader X, protecting users from malicious PDFs.  Additional information on Acrobat’s implementation of sandboxing is available on the Adobe Secure Software Engineering Team’s (ASSET) blog.  For those savvy in digital signatures, note that Protected Mode (on both Acrobat and Reader) may impair the installation of PKCS#11-based tokens.  Refer to the simple instructions here for a workaround.

And if you’re like me and love the nitty-gritty details of digital signatures, you’ll probably appreciate the other signature-specific changes in 10.1…

Continue reading…