Search Results for "sandbox"

Flash Player Sandbox Now Available for Safari on Mac OS X

Over the last few years, Adobe has protected our Flash Player customers through a technique known as sandboxing. Thus far, we have worked with Google, Microsoft and Mozilla on deploying sandboxes for their respective browsers. Most recently, we have worked with Apple to protect Safari users on OS X. With this week’s release of Safari in OS X Mavericks, Flash Player will now be protected by an OS X App Sandbox.

For the technically minded, this means that there is a specific com.macromedia.Flash Player.plugin.sb file defining the security permissions for Flash Player when it runs within the sandboxed plugin process. As you might expect, Flash Player’s capabilities to read and write files will be limited to only those locations it needs to function properly. The sandbox also limits Flash Player’s local connections to device resources and inter-process communication (IPC) channels. Finally, the sandbox limits Flash Player’s networking privileges to prevent unnecessary connection capabilities.

Safari users on OS X Mavericks can view Flash Player content while benefiting from these added security protections. We’d like to thank the Apple security team for working with us to deliver this solution.

Peleus Uhley
Platform Security Strategist

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!

Leveraging the Android Sandbox with Adobe Reader

Hi, Dimitri here. Now that the new Adobe Reader X sandbox has shipped, we are often asked about Adobe Reader for Android. Protecting our phones is increasingly important as more users are relying on them to access sensitive information, such as financial data, location tracking and email. Our use of mobile phones is different from our use of laptops, and there are more security threats to consider with these devices.

The Android Security Model

From a security point of view, the Android operating system is a multi-user Linux system where each application is a different user. This implies that any Linux 2.6 kernel bug that allows a local attacker to gain root privileges is also a potential Android vulnerability. While Android relies on Linux kernel security to achieve isolation between applications, it also provides some extra communication mechanisms of its own that allow different applications to talk to each other. These mechanisms give the operating system and each application fine-grained control over how they can interact.

There are many advantages to isolating different applications. One important benefit is that different applications cannot interfere with each other, unless the communication is mutually consensual. It also means that the principle of least privilege is applied by default, which makes the system more secure.

An Android application needs to be granted permission to access the user’s contact list, to read GPS location data, to access the network, and to do many other things. By default, it does not have permission to do any of this. If an application needs permissions to work, it must ask for those permissions at install time by listing them in its AndroidManifest.xml file. Also at installation time, the Android system will ask the user whether the application should be given the requested permissions. If permissions are granted, Android enforces compliance from then on.

Adobe Reader for Android

I hope you read the previous blog posts about the excellent work the Adobe Reader team has done to implement a sandbox in Adobe Reader X on Windows. With sandboxing, even if an attacker takes over an application’s process, he cannot cause severe harm to the user unless he also manages to break out of the sandbox.

In a sense, Android has sandboxing built-in. Every application in the Android system can be automatically sandboxed. This is great for the system’s security! Adobe has taken full advantage of this feature with Adobe Reader X. Here is the AndroidManifest.xml file for Adobe Reader:

<manifest versionCode="35282" versionName="10.0.0" installLocation="0"
                    package="com.adobe.reader">
   <application label="Adobe Reader" icon="res/drawable-hdpi/icon.png"
                    debuggable="true">
      <activity theme="@16973830" label="Adobe Reader" name=".AdobeReader"
                    launchMode="2" screenOrientation="2" configChanges="0xa0">
         <intent-filter>
            <action name="android.intent.action.MAIN">
            </action>
            <category name="android.intent.category.LAUNCHER">
            </category>
         </intent-filter>
         <intent-filter>
            <action name="android.intent.action.VIEW">
            </action>
            <category name="android.intent.category.DEFAULT">
            </category>
            <data mimeType="application/pdf">
            </data>
         </intent-filter>
      </activity>
      <activity theme="@2131034112" name=".ARAboutActivity">
      </activity>
      <activity theme="@16973830" name=".ARFileOpen" configChanges="0xa0">
      </activity>
      <activity theme="@16973830" name=".ARPortfolioUI">
      </activity>
   </application>
   <uses-sdk minSdkVersion="7">
   </uses-sdk>
</manifest>

The most important thing to notice is what is missing from this file. Adobe Reader does not ask for any permissions. As it turns out, we currently do not need to ask for any extra permissions to render documents. This means that Adobe Reader on Android already comes in a nice and strict sandbox.

If an attacker creates a malicious PDF file and is able to take over the Adobe Reader application running on your phone, he can run down your battery. He may also be able to use up all system resources or to brick your phone by sending multiple messages to the screen. He cannot, however, read your contact list, obtain your GPS location data, turn your camera on or even access the network! Unless there is a security bug in Android, all the attacker can do is perform a Denial-of-Service attack on your phone, which is undoubtedly extremely inconvenient, but not as costly as losing control of your personal information.

This fine-grained permissions-based sandbox-ready security model is currently only available on Android. Reader mobile users that have an Android phone should know that, even though this is not our first line of defense, Adobe Reader makes full use of Android’s application sandbox.

The Year of the Sandbox isn’t Over Yet!

Peleus here. It may be December, but we still have time to squeeze one more sandbox into what some security people have referred to as “the year of the sandbox.” We recently posted a number of blogs describing the design and testing that went into the Adobe Reader X sandbox. So, what about Adobe Flash Player? Flash Player already supports Protected Mode in Internet Explorer on Windows 7 and Windows Vista, which helps run Internet Explorer and Flash Player in a low integrity process. However, this only helps a subset of Windows users.

To further extend our sandboxing efforts, Adobe has been working with Carlos Pizano and the Google Chrome team on a prototype sandbox for Flash Player within the Chrome browser. Today, the Chrome team published a brief introduction to the effort on the Google Chrome blog. The associated Chrome and Flash Player builds have been published on the Chrome developer and canary channels.

We have enabled sandboxing support within Chrome’s integrated version of Flash Player (gcswf32.dll). For initial testing, the sandboxing code currently supports Windows XP, Windows Vista and Windows 7. There are plans to make this available for all OS platforms once we are further along in testing and development. For Windows operating systems that support UAC, the sandbox allows Flash Player to run as a low integrity process.

Over the next few months, we will be testing and receiving feedback on this project. Since this is a distinctly different sandboxing code base from Internet Explorer, we are essentially starting from scratch. Therefore, we still have a few bugs that we are working through. We hope that we can use this experience as a platform for discussing sandbox approaches with the other browser vendors.

The Flash Player team and the Adobe Secure Software Engineering Team (ASSET) are excited to explore this area as an additional defense for protecting our end-users. In addition to sandboxes, we are moving forward in parallel with other Flash Player defenses, such as JIT spraying mitigations. I plan to discuss some of those features in a future blog post. In the meantime, please check out the Google Chrome blog, and if you are a Chrome user, please help us test this new approach.! Thanks to Carlos Pizano and the Google Chrome team for all their assistance in helping drive this project!

Inside Adobe Reader Protected Mode – Part 4 – The Challenge of Sandboxing

Hi, Scott Stender from iSEC Partners here.   I was invited by the Adobe Secure Software Engineering Team (ASSET) to comment on our analysis of the sandbox through several stages in its development.  Of course, numerous individuals — at Adobe, iSEC and Matasano — were involved in its assessment, so please take this as one person’s perspective.  Even so, I would be remiss if I didn’t acknowledge the great work of Andreas Junestam, Andrew Becherer, Alex Vidergar, Chris Clark, and Justine Osborne of iSEC Partners, as well as the good folks at Matasano and Adobe who worked closely with us.

Creating a sandbox is perhaps the most difficult security engineering task one can undertake.   Some readers will take immediate objection to that statement – documentation is readily available online for using restricted tokens, chroot jails, and other sandbox building materials.   While it is indeed simple to place a restricted wrapper around a minimal service or piece of demonstration code, placing large applications, with all of their dependencies, in a sandbox presents an entirely different challenge.

A perfect sandbox is akin to the perfectly secure computer – the “…one buried in concrete, with the power turned off and the network cable cut.”  A sandbox is distinguished by the restrictions it places on a piece of running code.  Software, on the other hand, is evaluated based on its usefulness.  Balancing these competing goods – preventing bad software from doing bad things, while allowing good software to be useful – is the impossible challenge the sandbox engineer faces.

The Adobe Reader team has undertaken what may well be the most ambitious attempt to sandbox a Windows application to date:  Millions of lines of existing code, a third-party development platform, every multimedia technology under the sun, all now running in an entirely new execution environment.  It is hard to overstate the challenge of doing so and the accomplishment of getting there.

Securing the Sandbox
Our role as security advisors was to provide three major services to Adobe throughout the development of the sandbox: design review, code review, and penetration testing.

The design review was performed early in the development of the sandbox, with our feedback covering everything from options to provide process-level isolation to the best way to secure an individual API call.

Integrating all supported features from Adobe Reader 9 into the sandboxed version was a priority for Adobe.  As design reviewers we were often called on to suggest mechanisms to support sometimes scary functionality in a controlled fashion.  It was during this stage that we first encountered a recurring challenge – supporting a sandbox across multiple versions of Windows. Let me explain.

Adobe Reader was designed to support every Windows operating system from Windows XP to Windows 7.  Technical readers are well aware that a major change was made to the Windows security model in Windows Vista – User Account Control (UAC).  Less technical readers will know this feature by the pop-ups that request permission to execute sensitive programs.  An obvious challenge is creating a sandbox without the inherent isolation that UAC provides. A less obvious challenge is supporting  Windows XP without system-wide changes that were made to accommodate restricted processes.

iSEC performed reverse engineering and directed testing to identify workarounds that allowed the sandbox to work seamlessly on all supported platforms.  Once a basic level of functionality was achieved, the bulk of our design work went into feature-by-feature reviews of those areas that required coordination with the broker process.  Thankfully, we were able to test our own design suggestions in the code review and testing phases, providing an important feedback loop throughout our project.

The code review was surprisingly limited for a project of this size.  Our scope was the sandbox infrastructure, not the whole of Adobe Reader, so our targets for formal review were only on the order of tens of thousands of lines of sandbox-specific code.  No problem, right? The challenge of code review was that this relatively small amount of critically sensitive code obscured a large amount of underlying complexity.  The broker process is responsible for carrying out sensitive actions on behalf of the sandboxed Reader process; the broker is responsible for validating the request and calling Windows APIs with data passed by the sandbox.  The danger is that these APIs are often not designed to be resilient when called directly by an attacker.

The Windows security model contains several points of control – IPC mechanisms, data received over a network, and so on.  In the general case, calling a library function is not one of those points of control.  For example, take a look at the Platform SDK, find an API that accepts a pointer, and pass a non-NULL, but invalid value.  It is almost certainly going to crash your process, and that’s okay.  In this example, we just caused a denial of service against our own process – not a security bug.  Most programming platforms – UNIX system programming interfaces, the Java SDK, .Net Framework, and others – maintain a similar assumption: A process will not attack itself.

Not so with the sandboxed Adobe Reader.  Put simply, the sandbox and broker introduce a security boundary where one did not exist before.  As the sandbox developer, it is Adobe’s job to make sure that calls across this new security boundary are secure and well-behaved.

Code review had two major goals:  identify implementation-level flaws in the broker process and ensure that API parameter data passed from the sandbox is properly validated before being passed to a Windows API.  The first goal can be accomplished via straightforward code review; the second was an interesting challenge:

The Windows Platform SDK is an abstract API.  Microsoft states that the underlying implementation can change in any version and that only documented functionality is supported for use by developers.  Our goal as security reviewers was to help define what a “safe call” under these circumstances was – across all supported Windows platforms and with all supported callers.  Clearly, documentation review and reverse engineering are helpful. However, we needed to perform some serious testing of our assumptions.  That brings us to the next phase.

Testing provided the most intellectually challenging phase of the project.  In addition to the standard “find bugs” goal of testing, this phase helped define and refine the major attack surfaces of the sandboxed Reader process and its broker.  We focused on three areas: test infrastructure development, directed testing of sandbox and broker, and automated testing of the broker.

Our tests against prototype builds of the Reader process were painfully inefficient.  We used a combination of debugging tools, custom DLL injection, and a lot of process restarts.  After a small amount of testing of this sort, we found that we could eliminate 90% of the labor required by investing in an efficient test infrastructure. iSEC built a suite of tools that hooked directly into the IPC channel between the sandboxed Adobe Reader and its broker process.  These tools allowed us to make raw requests in exactly the same context as the sandboxed process, without any pesky client-side validation of parameters.  Furthermore, our hooks could be controlled by a completely separate process, allowing us to build directed test tools and integrate into Adobe’s existing fuzzing infrastructure.  The combination of fast directed testing and automated testing allowed us to provide broad and deep coverage of broker functionality exposed to the sandbox.  Our findings, in turn, helped modify our code review targets, resulting in a virtuous cycle of improved security on each review/test iteration.

Next Steps for the Sandbox
Engineering is a fundamentally human endeavor.  We do what is useful within our constraints, and iterate through progressively more useful and better-built versions.  It is easy to lose track of this fact amid talk of robust testing and code review.

Engineering the sandbox had its own set of constraints: Some risky functionality was just too important to omit altogether, and some changes to the code base could not be undertaken if we wanted to benefit from a sandboxed Adobe Reader within an acceptable timeframe.  In a threat landscape that constantly changes, there is no limit to the amount of testing one could do. Even as I write this I can think of more tests I would like to run, more investigation into platform technologies, and more isolation mechanisms to employ.  No doubt, some readers of this article have similar ideas and will report them as feedback and flaws to Adobe. Adobe has taken the first step in its attempt to minimize the impact of attacks on Adobe Reader with sandboxing- and it’s a huge step. Now, the Adobe Reader team can continue to refine its new security model based on feedback from users and security experts alike.  I look forward to seeing your thoughts now that Adobe Reader X is in your hands!

Scott Stender
iSEC Partners
scott@isecpartners.com

Inside Adobe Reader Protected Mode – Part 2 – The Sandbox Process

We continue our technical tour of Adobe Reader Protected Mode with a closer look at the sandbox process. (Check out part one of this series, if you missed it.) In today’s blog post we will look at all of the different ingredients the Windows operating system provides for a sandbox and see how those ingredients are used in the sandbox process to restrict access.

Figure 1 - Sandbox Process

Figure 1 - Sandbox Process

Process Level Granularity

For a sandboxed process, adhering to the principle of least privilege means that in many cases, the process can’t do much besides talk to the broker process. On Windows, code cannot perform any form of input-output task (I/O) to disk, keyboard, or screen without making a system call. Most system calls cause Windows to perform some sort of security check. The Adobe Reader sandbox process runs in an environment where these security checks fail for restricted actions.

The security check point of failure acts like a security fence, containing the sandboxed code. For Adobe Reader, that means limiting the code’s functionality by imposing a well-defined set of restrictions provided by the Windows security model. These include:

  • Limiting the token for the sandbox process:
    • Denying or restricting security identifiers (SIDs)
    • Removing privileges
  • Assigning the sandbox to a job object with restrictions
  • Running the sandbox process at low integrity on Windows Vista, Windows 7, and Windows Server2008

The Adobe Reader team uses these Windows operating system features to mitigate certain classes of attacks to help defend against attempts by a malicious PDF file seeking to exploit a vulnerability in Adobe Reader.

Restricting Security Identifiers (SIDs) and Privileges

One layer of protection is provided by restricting permissions to read, write, execute, etc. on the relative trustworthiness of the process owner. Identifying the owner’s role-specified rights and privileges occurs via a security access token when the user logs on. In Windows security parlance, the Reader user is a “trustee.” Any process the trustee invokes will execute in a security context which is partially defined by the access token.
The access tokens consists of two primary components: Security Identifiers (SIDs) and privileges. Windows fully describes the security context of every process that runs on behalf of the trustee by setting these two components. Reader modifies that context for sandboxed processes as follows:

  • Denying or restricting SIDs. Target process SIDs are modified by:
    • Marking all SIDs DENY_ONLY except for BUILTIN\Users, Everyone, User’s Logon SID, NTAUTHORITY\INTERACTIVE.
    • Adding the following SIDs to the restricting SID list: BUILTIN\Users, Everyone, User’s Logon SID, NTAUTHORITY\RESTRICTED.
  • Adding a low integrity level SID (for Vista, Windows 7, and Windows Server 2008 only).
  • Removing privileges. All privileges except the SetChangeNotifyPrivilege are removed from target process access tokens.

Through these methods, Adobe Reader further restricts the access token to limit access to securable objects or perform privileged operations. 

Figure 2 - Deny SIDs, Restricted SIDs, Privileges removed

Figure 2 - Deny SIDs, Restricted SIDs, Privileges removed

Job Objects

For certain tasks, groups of target processes can be grouped and managed as a unit in a job object. Windows Job objects are securable objects that control its processes attributes. Therefore, a job object can enforce additional global restrictions on all processes with which it is associated. Like other securable objects, access to job objects are controlled with a security descriptor. The Adobe Reader sandbox processes are placed in a job with the following restrictions: 

  • ActiveProcess – ActiveProcess limit of 1
  • Desktop Limited – Inability to create/switch to desktops
  • Display Settings – Inability to call ChangeDisplaySettings
  • Exit Windows – Inability to exit Windows via ExitWindows(Ex)
  • USER Handles – Inability to use USER handles owned by processes not associated with the same job
  • System Parameters – Inability to change system parameters via the SystemParametersInfo function
  • Administrator Access – Prevents any process in the job from using a token that specifies the local administrators group

These limitations prevent malicious code in the sandbox from tampering with different parts of the operating system.

Figure 3 - Job Object Limits

Figure 3 - Job Object Limits

Low Integrity

The Windows integrity mechanism is a component of the Windows architecture that restricts application access permissions by assigning integrity levels (essentially trustworthiness markers) to all processes and securable objects. While not a silver bullet on its own, the addition of the integrity mechanism starting with Windows Vista was a huge leap forward for implementing the sandbox because it enforces access restrictions to so many different parts of the operating system. Resource managers such as the file system block less trustworthy processes from modifying objects of higher integrity. For Adobe Reader, target processes run as a low integrity processes which prevents them from communicating with processes of higher integrity. This mechanism provides a form of mandatory access control for process-level granularity. Since integrity is a feature that’s only available on Windows Vista and later, it means that the sandbox on these platforms offer stronger protection than the sandbox on Windows XP. 

Process Explorer

The screen shots in figure 2 and figure 3 above are from the Process Explorer tool. A quick way to assess the operating system protections used by a sandbox in Windows is to look at the sandbox process in Process Explorer. For fun, compare the ‘Security’ and ‘Job’ tabs in Process Explorer for different applications that claim to have a sandbox or protected mode and see how they stack up against each other.

No Separate Desktop for Adobe Reader Protected Mode

The third part of David LeBlanc’s Practical Windows sandboxing recommended putting your sandboxed process into a separate desktop, because there is very little security within a Windows desktop. The Adobe Reader engineering team evaluated the possibility of running Adobe Reader in a separate desktop but came to the conclusion that doing so would require significant architectural changes that would delay our ability to provide an Adobe Reader sandbox until well into 2011. (Building a sandbox into an application as complex as Adobe Reader has been compared to adding a basement to a 20-story building after it’s already been erected.)
So, the challenge became:  Could we provide nearly all of the mitigations a separate desktop provides using other techniques?  The answer is: Yes, we can. This section describes how we did it in detail, as well as the limitations.

(A special word of thanks to David LeBlanc of the Microsoft Office team, and Nicolas Sylvain of the Google Chrome team for their help exploring the alternatives.)

Shatter Attack

One attack that a separate desktop would mitigate against is known as the Shatter Attack. To prevent shatter attacks, we need to ensure our sandbox process cannot send window messages to windows owned by other processes, unless explicitly granted permission to do so.
We were able to mitigate against these attacks with Adobe Reader Protected Mode on Windows XP SP3 and higher using two techniques:

Our job object sets the UILIMIT_HANDLES restriction.  This prevents the sandboxed process from accessing user handles created by processes not associated with our job.

On Windows Vista and later, we also run the sandboxed process at low integrity. With User Interface Privilege Isolation (UIPI), processes are prevented from sending messages to windows owned by processes running at a higher integrity level.

Abuse of SetWindowsHookEx

SetWindowsHookEx is a powerful Windows API that can allow malware to insert itself into any process running in the same desktop. Running your sandboxed process in a separate desktop would prevent this from happening.

Despite not running in a separate desktop, we were able to mitigate against these attacks with Adobe Reader Protected Mode using these techniques:

  • Our job object sets the UILIMIT_HANDLES restriction. This prevents the sandboxed   process from setting hooks into processes not associated with our job.
  • The Adobe Reader sandbox is running with a restricted token. Due to the restricted token, Windows does not trust our process to set a hook.
  • On Windows Vista and later, we also run the sandboxed process at low integrity. With User Interface Privilege Isolation (UIPI), processes are prevented from setting hooks into processes running at a higher integrity level and cannot inject DLLs using SetWindowsHookEx.

Transient Key Loggers

Key logging malware attempts to steal valuable information by logging keystrokes in other processes. Ideally, using a separate desktop for the sandboxed process would prevent this type of attack.

Despite not running in a separate desktop, we were able to mitigate against these attacks with Adobe Reader Protected Mode, but only on Windows Vista, Windows Server 2008 and Windows 7:

  • On Windows Vista and later, we also run the sandboxed process at low integrity. With User Interface Privilege Isolation (UIPI), processes are prevented from reading key strokes in processes running at a higher integrity level.

Screen Scraping Attacks

Running the sandboxed process on a separate desktop can mitigate against malware that attempts to steal information by scraping the screen.  

Given the UIPI/restricted-token/handles restriction capabilities of our sandbox, we can mitigate against the screen scraping attack without running in a separate desktop. Unfortunately, we could not implement it this time around because lot of our code in Adobe Reader requires explicitly giving handle access to the desktop window handle. We plan to explore this further in a later dot release.

Conclusion

This concludes the detailed view of the Adobe Reader sandbox process and how it leverages the Windows OS security model to thwart persistent malware and transient key logger type of attacks. In the next post, we will explore the broker process in more detail. Special thanks to Tom Keetch for providing some valuable insight into the details of some low-level access controls used by the sandbox.

On a related note, we just added a session titled “Sandboxing Adobe Reader: Protected Mode” to the schedule for users attending Adobe MAX 2010, held in Los Angeles from October 23-27, 2010. Speakers will be Suchit Mishra, Acrobat lead security researcher and Joel Geraci, Acrobat technical evangelist. For details, visit: https://max.adobe.com/schedule/by-session/sandboxing-adobe-reader-protected-mode/1f420056-b205-4729-b135-d98d72c8c658.

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

Flash Player Security with Windows 8 and Internet Explorer 10

With the launch of Internet Explorer 10 on Windows 8 last year, customers have experienced improved Flash Player capabilities. Adobe worked closely with Microsoft to integrate Flash Player into Internet Explorer 10 for the Windows 8 platform, but some of our customers are still unaware of the full benefit of the security enhancements. We’d like to take the opportunity to discuss how this integration introduced several new changes that have increased end-user security.

The first significant change is that Flash Player updates for IE 10 on Windows 8 are now distributed through Windows Update. End-users are no longer prompted by the Flash Player auto-updater to update Internet Explorer. This also means that enterprises can now distribute Flash Player updates for Windows 8 through their existing Windows OS patch management workflows. For IE 10 users on Windows 7, you will continue to be updated through Flash Player’s existing update mechanisms.

Windows 8 and IE 10 bring a new level of security known as Enhanced Protected Mode (EPM). In immersive mode, EPM is enabled by default. End users can enable Enhanced Protected Mode on the desktop by selecting Tools > Internet Options > Advanced and checking “Enable Enhanced Protected Mode.”

EPM on IE 10 provides several new protections. One is that all content processes will run as 64-bit processes. This means that Flash Player will also be run as a 64-bit process which will make heap sprays more difficult. The larger address space makes it more difficult to predict the memory location of the spray with a decent statistical likelihood.

The Windows 8 OS security model also utilizes AppContainers for Windows Store. The AppContainer for Internet Explorer 10 is an improvement on the existing idea of Integrity levels. The IE 10 AppContainer brokers both read and write access to most of the operating system. This is an improvement over traditional Protected Mode where only write access was limited. Since Flash Player will be executing as a low privileged process, it will not be able to read user-owned data without user interaction. In addition, the IE 10 AppContainer enforces certain network restrictions which are described here. Since Flash Player is integrated into IE 10, Flash Player is sandboxed by the same AppContainer broker as Internet Explorer.

One aspect of the new AppContainer brokers is that Internet Explorer 10 has an unique cookie store for each mode. Browser cookies for immersive surfing will be placed in the IE 10 AppContainer storage location. Cookies created while surfing Internet-zone content in IE 10 on the desktop will be placed in the Low Integrity Level (LowIL) cookie location. Flash Player acknowledges this paradigm for Local Shared Objects (LSOs), as well. This means that any data stored from your Flash Player gaming in immersive mode will not be available to Flash Player when you are surfing with IE on the desktop. More information on how IE 10 handles cookies on Windows 8 can be found in this blog.

Overall, these new protections serve to further improve security for our Windows 8 customers while also delivering a more streamlined update workflow. Adobe will continue to work with Microsoft to better improve security for our mutual customers going forward.

Peleus Uhley
Platform Security Strategist

Reflections on Black Hat & DefCon

This year the ASSET security team along with security engineers from several other Adobe teams travelled to Vegas to attend the summer’s largest security conferences – Black Hat and DefCon. The technical talks can typically range from “cool bugs” to “conceptual issues that require long term solutions.” While the bugs are fun, here’s my take on the major underlying themes this year.

One major theme is that our core cryptographic solutions such as RSA and TLS are beginning to show their age. There was more than one talk about attacking TLS and another presentation by iSEC Partners focused on advances related to breaking RSA. The iSEC team made a valid case that we, as an industry, are not prepared for easily deploying alternative cryptographic solutions. Our industry needs to apply the principles of “crypto agility” so that we can deploy alternative solutions in our core security protocols, should the need arise.

Another theme this year was the security issues with embedded systems. Embedded systems development used to be limited to small bits of assembly code on isolated chips. However, advances in disk storage, antenna size, and processors has resulted in more sophisticated applications powering more complex devices. This exposed a larger attack surface to security researchers at Black Hat and DefCon who then found vulnerabilities in medical devicesSIM cardsautomobilesHVAC systemsIP phonesdoor locksiOS chargersSmart TVsnetwork surveillance cameras, and similar dedicated devices. As manufacturing adopts more advanced hardware and software for devices, our industry will need to continue to expand our security education and outreach to these other industries.

In traditional software, OS enforced sandboxes and compiler flags have been making it more difficult to exploit software. However, Kevin Snow and Lucas Davi showed that making additional improvements to address space layout randomization (ASLR), known as “fine-grained ASLR,” will not provide any significant additional levels of security. Therefore, we must rely on kernel enforced security controls and, by logical extension, the kernel itself. Mateusz Jurczyk and Gynvael Coldwind dedicated significant research effort into developing tools to find kernel vulnerabilities in various operating system kernels. In addition, Ling Chuan Lee and Chan Lee Yee went after font vulnerabilities in the Windows kernel. Meanwhile, Microsoft offered to judge live mitigation bypasses of their kernel at their booth. With only a small number of application security presentations, research focus appears to be shifting back toward the kernel this year.

Ethics and the law had an increased focus this year. In addition to the keynote by General Alexander, there were four legal talks at Black Hat and DefCon from the ACLU, EFF and Alex Stamos. Paraphrasing Stamos’ presentation, “The debate over full disclosure or responsible disclosure now seems quaint.” There were no easy answers provided; just more complex questions.

Regardless of the specific reason that drew you to Vegas this year, the only true constant in our field is that we must continue learning. It is much harder these days to be an effective security generalist. The technology, research and ethics of what we do continues to evolve and forces deeper specialization and understanding. The bar required to wander into a random Black Hat talk and understand the presentation continues to rise. Fortunately, walking into a bar at Black Hat and offering a fellow researcher a drink is still a successful alternative method of learning.

Peleus Uhley
Platform Security Strategist

Reader 9.x Reaches End-of-Life

In line with the Adobe Support Lifecycle Policy, Adobe’s Acrobat 9.x and Reader 9.x suite of products reached their end-of-life (EOL) today, June 26, 2013. This means that Adobe will no longer provide security or other updates to this product suite.

Over the years, we’ve made several security enhancements in the successors of Reader 9, Reader X and Reader XI, including the Protected Mode (aka “sandboxing”) and Protected View. There has never been a better time to upgrade to Reader XI. Please upgrade, ensure automatic updates are turned on, and stay secure!

Karthik Raman

Security Researcher, ASSET

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