Posts tagged "SWF"

Click-to-Play for Office is Here!

Last week, we introduced a new Flash Player feature that includes a new Microsoft Office click-to-play capability that determines whether Flash Player is being launched within Microsoft Office and automatically checks the version of Office. Launching Flash Player 11.6 from within a version of Office older than Office 2010 will prompt the end-user before executing the Flash content, ensuring potentially malicious content does not immediately execute and impact the end-user. This feature adds another layer of defense against spearphishing attacks by allowing the end-user an opportunity to realize that they have opened a potentially malicious document and close it before the exploit executes.

Click-to-Play for Office should make this attack vector less attractive for attackers. Please update your environments to Flash Player 11.6 as soon as possible.

Peleus Uhley, Platform Security Strategist, ASSET

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

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

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!