Posts tagged "security"

Looking Back at the Grace Hopper Celebration

As someone new to the Grace Hopper Celebration (GHC), I was excited and overwhelmed on realizing there were around 8000 women from more than 60 countries. I had the opportunity to meet some really interesting people from within and outside of Adobe.

The keynote by Shafi Goldwasser (winner of the 2012 ACM Turing award) was especially interesting. She discussed cryptography and the varied, seemingly paradoxical solutions it can help us achieve. Highlighting the need to store data privately in the cloud with the ability to simultaneously harness that data to solve problems (e.g. research in medicine), she emphasized that the “magic of cryptography” as the key to this, and spoke at some length on looking at problems through the “cryptographic lens.”

Dr. Arati Prabhakar’s (Dir of DARPA) keynote during the award ceremonies was very inspiring. She talked about the benefits military research has provided to areas like the Internet, material sciences and safer warfare, and talked about further research into new areas, such as producing new materials and chemicals and rethinking complex military systems. She even showed the audience a video of a robotic arm being controlled by a quadriplegic woman hooked up to a computer.

The majority of presentations I attended were related to security, where I met smart and motivated women working in the security field, and a lot of students interested in security. The talks varied from Lorrie Cranor’s talk on analyzing and storing passwords safely, to a panel discussion integration of security in SDLC (panelists included Justine Osborne, Leigh Honeywell and Parisa Tabriz) to homomorphic encryption and its future uses (Mariana Raykova and Giselle Font). Other talks ranged from security fundamentals and cryptography aimed at college students to more “hot topics” like wearable technology, biometrics, cloud computing and HCI.

I also helped out at the career fair, and met a lot of undergraduates interested in working with Adobe. It was fun talking with them about what I do and learning about what they were interested in, including two students Adobe had sponsored to attend GHC this year. I met a number of industry professionals as well as students at talks and events who are working on including more girls and women in tech through outreach programs, hackathons and mentoring. It was refreshing to see a few men attending the GHC too.

The theme of the GHC this year was “Everyone, Everywhere.” It was a very inclusive environment, and apart from the talks there were events to make our evenings fun- ice breakers and dances. The long list of impressive speakers, motivating panelists and encouraging mentors/organizations were all very accessible and inspiring. I had a great time at GHC and I hope more people (men and women!) get to attend the conference in the future.

Devika Yeragudipati
ASSET Security Researcher

Join Us at ISSE EU in Brussels October 14 – 15!

Adobe will be participating again this year in the ISSE EU conference in Brussels, Belgium, Oct. 14-15, 2014. This conference attracts senior decision makers in IT Security from a wide range of industries and governmental organizations. There are numerous sessions tackling many of the current hot topics in security including cloud security, identity management, the Internet of Things (IoT), data protection & privacy, compliance & regulation, and the changing role of IT Security professionals adapting to these changes. 

Adobe will be talking about a few of our security initiatives and programs during the event, specifically highlighting our security training program which I currently manage. The materials from this program now form the basis of the open-source, free security training program from SAFECode (https://training.safecode.org). Many organizations have now used these materials to develop their own security training programs. I will be available on-site to answer questions about these programs. 

We will also have three sessions during the conference. Director of Product Security David Lenoe will present a keynote presentation on “Maintaining a Security Organization That Can Adapt to Change” on Tuesday, Oct. 14, at 11:45 a.m. According to Forrester Research, “51 % of organizations said it’s a challenge or major challenge to hire security staff with the right skills” – and keeping them happy, productive, and nimble is also a major challenge. This session will discuss Adobe’s approach to addressing these issues in our organization that we believe may provide valuable insight into handling these issues in your own organization. 

On Tuesday at 3:10 p.m., Mohit Kalra, senior manager for secure software engineering, will provide insight into “Deciding the Right Metrics & Dashboards for Security Success.” This session will discuss what makes a “good” security roadmap and then how to properly measure and share progress against that roadmap to help ensure success.  

Last but not least, on Wednesday, Oct. 15, at 2:40 p.m. I will discuss how “Building Security In Takes Everyone Thinking Like a Security Pro.” While we realize this is a mouthful, it’s probably best description I can give for the goal of the ASSET Certification Program (http://blogs.adobe.com/security/2013/05/training-secure-software-engineers-part-1.html) at Adobe. We as an industry not only need to increase our security fluency, we also need to have people that can look at the product they are working on with a hacker’s eye and raise a flag when they see something that may become an issue in the future.  

In this talk, I will spend most of the time dedicated to the experiential elements of the program that gives us the ability to build our experts. For example, people have taught themselves how to perform manual penetration testing. On the flip side there are a lot of projects where candidates have created ways to automate scanning or other processes. One of the more innovative projects was the creation of the Hackfest (http://blogs.adobe.com/security/?s=hackfest&submit=). As one security champion, Elaine Finnell, puts it, “For myself, pursuing the brown belt (in the program) has pushed me beyond simply absorbing information and into doing. Similar to how a science classroom has a lab, putting the information I learn both during the training and during outside trainings into practice helps to solidify my understanding of security principles. While I’m still not an expert on executing penetration testing, fuzzing, or architecture analysis, every experience I have doing this type of work alongside experts serves to improve my ability to be a security champion within my team.”

I love to talk about this stuff. I’ll be available in Adobe’s booth on the expo floor and if you’re going to be there, so please hit me up. I’m also available on Twitter – @JoshKWAdobe. More information about the training program can also be found in our new white paper available at http://www.adobe.com/content/dam/Adobe/en/security/pdfs/adobe-security-training-wp-web.pdf and on the Security@Adobe blog (http://blogs.adobe.com/security/2013/05/training-secure-software-engineers-part-1.html).

You can follow @AdobeSecurity for the latest happenings during ISSE EU as we will be live tweeting during the event – look for the hashtag #AdobeISSE. Also, more information about all of our security initiatives can be found at http://www.adobe.com/security.   

 


Josh Kebbel-Wyen 

Senior Security Program Manager 

Observations From an OWASP Novice: OWASP AppSec Europe

Last month, I had the opportunity to attend OWASP AppSec Europe in Cambridge.

The conference was split into two parts. The first two days consisted of training courses and project summits, where the different OWASP project teams met to discuss problems and further proceedings, and the last two days were conference and research presentations.

Admittedly an OWASP novice, I was excited to learn what OWASP has to offer beyond the Top 10 Project most of us are familiar with. As it is commonly the case with conferences, there were a lot of interesting conversations that occurred over coffee (or cider). I had the opportunity to meet some truly fascinating individuals who gave some great insight to the “other” side of the security fence, including representatives from Information Security Group Royal Holloway, various OWASP chapters, and many more.

One of my favorite presentations was from Sebastian Lekies, PhD candidate at SAP and the University of Bochum, who demonstrated website byte-level flow analysis by using a modified Chrome browser to find DOM-based XSS attacks. Taint-tags were put on every byte of memory that comes from user-input and traced through the whole execution until it was displayed back to the user. This browser was used to automatically analyze the first two levels of all Alexa Top 5000 websites, finding that an astounding 9.6 percent carry at least one DOM-based XSS flaw.

Another interesting presentation was a third day keynote by Lorenzo Cavallaro from Royal Holloway University. He and his team are creating an automatic analysis system to reconstruct behaviors of Android malware called CopperDroid. It was a very technical, very interesting talk, and Lorenzo could have easily filled another 100 hours.

Rounding out the event were engaging activities that broke up the sessions – everything from the University Challenge to a game show to a (very Hogwarts-esque) conference dinner at Homerton College’s Great Hall.

All in all, it was an exciting opportunity for me to learn how OWASP has broadened its spectrum in the last few years beyond web application security and all the resources that are currently available. I learned a lot, met some great people, and had a great time. I highly recommend to anyone that has the opportunity to attend!

Lars Krapf
Security Researcher, Digital Marketing

Another Successful Adobe Hackfest!

ASSET, along with members of the Digital Marketing security team, recently organized an internal “capture the flag” event called Adobe Hackfest. Now in its third year, this 10-day event accommodates teams spread across various geographies. The objective is for participants to find and exploit vulnerable endpoints to reveal secrets. The lucky contestants that complete all hacks at each level are entered to win some awesome prizes.

This year, we challenged participants with two vulnerabilities to hack at two different difficulty levels, carefully chosen to create security awareness within the organization. Using the two hacks as teaching opportunities, we targeted three information security concepts under cross-site scripting, SQL injection and password storage categories. Our primary intention was to demonstrate consequences of using insecure coding practices via a simulated vulnerable production environment.

Contributing to the event’s success were logistics we’ve added from previous events to create a more seamless experience. The event was heavily promoted internally, and we had specific channels for participants to ask questions or request hints, including three hosted Adobe Connect sessions in different time zones.  The Digital Marketing security team also created a framework that generated unique secrets for every participant, and a leaderboard that would update automatically.

Participants worked very hard which generated stiff competition, with more than 50 percent unlocking at least one secret, and nearly 30 percent unlocking all four. Though our developers, quality engineers, and everyone else involved in shipping code undergo different information security trainings, this event helps bring theories into practice by emphasizing that there is no “silver bullet” when it comes to security, and the importance of a layered approach.

Participation was at an all-time high, and given the tremendous interest within Adobe, we are now planning to have Hackfests more frequently. Looking forward to Hackfest Autumn!

Vaibhav Gupta
Security Researcher

Top 10 Hacking Techniques of 2013: A Few Things to Consider in 2014

For the last few years, I’ve been a part of the annual ranking of top 10 web hacking techniques organized by WhiteHat Security. Each year, it’s an honor to be asked to participate, and this year is no different. Not only does judging the Top 10 Web Hacking Techniques allow me to research these potential threats more closely, it also informs my day-to-day work.

WhiteHat’s Matt Johansen and Johnathan Kuskos have provided a detailed overview of the top 10 with some highlights available via this webinar.  This blog post will further describe some of the lessons learned from the community’s research.

1. XML-based Attacks Will Receive More Attention

This year, two of the top 15 focused on XML-based attacks. XML is the foundation of a large portion of the information we exchange over the Internet, making it an important area of study.

Specifically, both researchers focused on XML External Entities. In terms of practical applications of their research, last month Facebook gave out their largest bug bounty yet for an XML external entity attack. The Facebook attack demonstrated an arbitrary file read that they later re-classified as a potential RCE bug.

Advanced XML features such as XML external entities, XSLT and similar options are very powerful. If you are using an XML parser, be sure to check which features can be disabled to reduce your attack surface. For instance, the Facebook patch for the exploit was to set libxml_disable_entity_loader(true).

In addition, JSON is becoming an extensively used alternative to XML. As such, the JSON community is adding similar features to the JSON format. Developers will need to understand all the features that their JSON parsers support to ensure that their parsers are not providing more functionality than their APIs are intended to support.

2. SSL Takes Three of the Top 10 Spots

In both the 2011 and 2012 Top 10 lists, SSL attacks made it into the top spot.  For the 2013 list, three attacks on SSL made it into the top 10: Lucky 13, BREACH and Weaknesses in RC4. Advances in research always lead to more advances in research. In fact, the industry has already seen our first new report against SSL in 2014.  It will be hard to predict how much farther and faster research will advance, but it is safe to assume that it will.

Last year at BlackHat USA, Alex Stamos, Thomas Ptacek, Tom Ritter and Javed Samuel presented a session titled “The Factoring Dead: Preparing for the Cryptopocalypse.” In the presentation, they highlighted some of the challenges that the industry is facing in preparing for a significant breach of a cryptographic algorithm or protocol. Most systems are not designed for cryptographic agility and updating cryptography requires a community effort.

These three Top 10 entries further highlight the need for our industry to improve our crypto agility within our critical infrastructure. Developers and administrators, you should start examining your environments for TLS v1.2 support. All major browsers currently support this protocol. Also, review your infrastructure to determine if you could easily adopt future versions of TLS and/or different cryptographic ciphers for your TLS communication. The OWASP Transport Layer Protection Cheat Sheet provides more information on steps to hard your TLS implementation.

3. XSS Continues to Be a Common Concern for Security Professionals

We’ve known about cross-side scripting (XSS) in the community for over a decade, but it’s interesting that people still find innovative ways to both produce and detect it. At the most abstract level, solving the problem is complex because JavaScript is a Turing-complete language that is under active development. HTML5 and CSS3 are on the theoretical edge of Turing-Completeness in that you can implement Rule 110 so long as you have human interaction. Therefore, in theory, you could not make an absolute statement about the security of a web page without solving the halting problem.

The No. 1 entry in the Top 10 this year demonstrated that this problem is further complicated due to the fact that browsers will try to automatically correct bad code. What you see in the written code is not necessarily what the browser will interpret at execution. To solve this, any static analysis approach would not only need to know the language but also know how the browser will rewrite any flaws.

This is why HTML5 security advances such as Content Security Policies (CSP) and iframe sandboxes are so important (or even non-standards-based protections such as X-XSS-Protection).  Static analysis will be able to help you find many of your flaws. However, due to all the variables at play, they cannot guarantee a flawless site. Additional mitigations like CSP will lessen the real world exploitability of any remaining flaws in the code.

These were just a few of the things I noticed as a part of the panel this year. Thanks to Jeremiah Grossman, Matt Johansen, Johnathan Kuskos and the entire WhiteHat Security team for putting this together. It’s a valuable resource for the community – and I’m excited to see what makes the list next year.

Peleus Uhley

Lead Security Strategist

 

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

Illegal Access to Adobe Source Code

Adobe is investigating the illegal access of source code for Adobe Acrobat, ColdFusion, ColdFusion Builder and other Adobe products by an unauthorized third party.  Based on our findings to date, we are not aware of any specific increased risk to customers as a result of this incident.

Adobe thanks Brian Krebs, of KrebsOnSecurity.com, and Alex Holden, chief information security officer, Hold Security LLC. holdsecurity.com  for their help in our response to this incident.

We are not aware of any zero-day exploits targeting any Adobe products. However, as always, we recommend customers run only supported versions of the software, apply all available security updates, and follow the advice in the Acrobat Enterprise Toolkit and the ColdFusion Lockdown Guide. These steps are intended to help mitigate attacks targeting older, unpatched, or improperly configured deployments of Adobe products.

For more information on Acrobat security, please visit the Acrobat Developer Center.

For more information on ColdFusion 10 security, please visit the ColdFusion Developer Center.

 

Brad Arkin

Chief Security Officer

New Role – Chief Security Officer

For those who may have seen the news and are looking for more context, I’ve put together a quick post about my new role as Adobe’s Chief Security Officer. While this is a newly created role at Adobe, it’s an expansion of responsibilities that builds upon on the initiatives I’ve been leading for nearly five years at the company.

As CSO, I will report to Bryan Lamkin, SVP of Technology and Corporate Development, and will work in partnership with Adobe’s global information technology team led by our CIO Gerri Martin-Flickinger. I will continue to oversee the Adobe Secure Software Engineering Team (ASSET), responsible for implementing our Secure Product Lifecycle that engineers products to be robust against attacks, as well as the Product Security Incident Response Team (PSIRT), responsible for managing response to product security incidents. In my new role, I have the opportunity to lead Engineering Infrastructure Security, a team that builds and maintains security-critical internal services relied on by our product and engineering teams, such as code signing and build environments. I will also continue to manage and foster two-way communication with the broader security community, a vital part of the central security function.

The driving goal behind our security work is to protect our customers from those who would seek to harm them. Adobe has some of the most widely-deployed software in the world and we are keenly aware that this makes us a target. We remain committed to doing everything we can to defend against the bad guys. I am excited to continue  leading the charge at Adobe!

Brad Arkin

Chief Security Officer

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