Adobe Flash Player 9 ® ® WHITE PAPER Adobe Flash Player 9 Security July 2006 Copyright © 2006 Adobe Systems Incorporated. All rights reserved. The information contained in this document represents the current view of Adobe on the issue discussed as of the date of publication. Because Adobe must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Adobe, and Adobe cannot guarantee the accuracy of any information presented after the date of publication. This white paper is for information purposes only. ADOBE MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT. Adobe may have patents, patent applications, trademark, copyright or other intellectual property rights covering the subject matter of this document. Except as expressly provided in any written license agreement from Adobe, the furnishing of this document does not give you any license to these patents, trademarks, copyrights or other intellectual property. Adobe, the Adobe Logo, Macromedia, Flash, Breeze, Central, ColdFusion, FlashCast, Flash Lite, Flex, and MXML are trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners. Adobe Systems Incorporated 345 Park Avenue San Jose, CA 95110 (408) 536-6000 Contents Introduction ...................................................................................................................................................1 About this document ....................................................................................................................................................................1 Other sources of information .....................................................................................................................................................2 Flash Player client runtime .........................................................................................................................................................2 The Flash Player security environment ...................................................................................................................................3 Stakeholders .........................................................................................................................................................................4 Overview of permission controls.......................................................................................................................................5 Sources for potential risk ....................................................................................................................................................6 Flash Player security claims ............................................................................................................................................... 7 New Security Features in Flash Player 9 ........................................................................................................................8 Flash Player security architecture ..............................................................................................................9 Basic sandbox security model...................................................................................................................................................9 Domain of origin ................................................................................................................................................................. 10 Default permissions ........................................................................................................................................................... 10 Accessing data in another sandbox ............................................................................................................................... 12 Permissions for specific domains ........................................................................................................................................... 13 Network files........................................................................................................................................................................ 13 Local files ............................................................................................................................................................................. 13 Interpreters and byte code ....................................................................................................................................................... 16 Background ......................................................................................................................................................................... 16 Code isolation ......................................................................................................................................................................17 Disk, memory, and processor protections ............................................................................................................................ 18 Disk storage protections................................................................................................................................................... 18 Memory usage protections and processor quotas ..................................................................................................... 18 The Verifier .................................................................................................................................................................................. 19 Permission controls .................................................................................................................................. 20 Administrative user controls....................................................................................................................................................20 The mms.cfg file ................................................................................................................................................................20 Global Flash Player Trust directory ............................................................................................................................... 22 User controls .............................................................................................................................................................................. 23 Settings Manager.............................................................................................................................................................. 23 Settings UI and runtime dialog boxes ........................................................................................................................... 26 Flash Player Trust directories and files ......................................................................................................................... 29 Website controls ....................................................................................................................................................................... 29 Policy file usage .................................................................................................................................................................30 Developer controls..................................................................................................................................................................... 31 Permission mechanisms ................................................................................................................................................... 31 Security.allowDomain().................................................................................................................................................... 33 Security.loadPolicyFile().................................................................................................................................................. 35 Security.exactSettings..................................................................................................................................................... 35 Security.sandboxType ..................................................................................................................................................... 35 LocalConnection.allowDomain() ................................................................................................................................... 36 Local file system options for authors ............................................................................................................................ 37 Options when publishing ................................................................................................................................................. 37 ActiveX control and browser plug-in APIs ................................................................................................................... 38 Hierarchy of local file security controls ................................................................................................................................. 38 Loading into the local-trusted sandbox........................................................................................................................ 38 Loading into the local-with-networking sandbox....................................................................................................... 39 The default setting: local-with-file-system................................................................................................................... 39 Flash Player integration with native applications........................................................................................................ 39 Deployment of the Flash Player runtime ................................................................................................. 40 Browser plug-ins and ActiveX controls................................................................................................................................40 Authoring player ......................................................................................................................................................................... 41 Stand-alone player and Flash projector................................................................................................................................ 41 Other distributions...................................................................................................................................................................... 41 Platform and runtime environment ........................................................................................................................................ 42 Deployment of Flash applications............................................................................................................ 43 SWF files .................................................................................................................................................................................... 43 Network SWF files............................................................................................................................................................ 43 Local SWF files ................................................................................................................................................................. 43 Executable projector files ........................................................................................................................................................ 44 Other security-related information .......................................................................................................... 45 Network protocols..................................................................................................................................................................... 45 AMF...................................................................................................................................................................................... 45 SMB ..................................................................................................................................................................................... 45 RTMP................................................................................................................................................................................... 45 HTTP.................................................................................................................................................................................... 45 HTTPS................................................................................................................................................................................. 46 TCP sockets ....................................................................................................................................................................... 46 SSL (Secure Sockets Layer) utilization............................................................................................................................... 47 Basic SSL—browser plug-ins ......................................................................................................................................... 47 Projector files...................................................................................................................................................................... 47 Introduction Security is a key concern of Adobe®, users, website owners, and content developers. For this reason, Adobe Flash® Player 9 includes a set of security rules and controls to safeguard the user, website owner, and content developer. This white paper provides an overview of the Flash Player security model About this document This document is intended for the following audience: • Enterprise architects who are evaluating or need to better understand the security model of the Flash Platform • IT managers interested in the security of Flash applications in their network environment • Website owners that deploy Flash applications from their sites • Developers (including programmers and other authors) designing and publishing Flash applications This document assumes that the reader is familiar with Flash and ActionScript, and their related terms, authoring tools, and environments. This document focuses on the security-relevant features of the Flash Player client runtime, including those previously introduced in earlier versions of the product. While not attempting to distinguish between versions, some references are included where changes in the security model or potential operation of applications designed and implemented in earlier versions of Flash Player may significantly differ from the target Flash Player environment described here. It is important, however, that there are no distinctions in the resulting runtime security model between applications created using different development tools, such as Adobe Flex™ Builder, the Adobe Flex SDK, or Adobe Flash. The preferred target platform is assumed (unless otherwise noted) to be Flash Player 9 running content that uses ActionScript 3.0. Flash Player 9 uses an entirely new ActionScript Virtual Machine (AVM2). AVM2 runs a much faster, ECMAScript standards-compliant language: ActionScript 3.0. AVM2 itself introduces some new architecture to this environment due to its enhanced byte code interpretation model. The prior AVM versions remain available to run ActionScript 1.0 and 2.0 content. Adobe Flash Player 9 Security 1 Other sources of information This document is not the only source of information on Flash Player security. The following provide more information: Document Audience Contains The “Flash Player Security” chapter in Programming ActionScript 3.0 Developers Detailed information for developers creating Flash Player 9 content The ActionScript 3.0 Language Reference (http://www.adobe.com/go/AS3LR) Developers Detailed information on all ActionScript 3 APIs that have security considerations. The Flash Player Administration Guide Administration/IT professionals Information on administering Flash Player in enterprise environments Flash Player Help End users Information on understanding/controlling security in client environment The “Understanding Security” chapter in Learning ActionScript 2.0 Developers Conceptual information for ActionScript 1.0 and 2.0 in Flash Player 8. The Flash Player 8 SecurityAPIs white paper Developers API-specific information for ActionScript 1.0 and 2.0 The Flash Player Security Topic Center All Articles, including information on changes in each Flash Player version. (www.adobe.com/go/programmingAS3) (www.adobe.com/go/fp9_admin) (http://www.adobe.com/ support/documentation/en/ flashplayer/help/index.html) (http://livedocs.macromedia.com/ flash/8/main/wwhelp/ wwhimpl/js/html/wwhelp.htm?href= Part3_Learning_AS.html) (http://www.adobe.com/devnet/ flashplayer/articles/ fp8_security-related_apis.pdf) (http://www.adobe.com/devnet/ security) Flash Player client runtime Adobe Flash Player runs Flash applications (also referred to as SWF files). Flash Player content is delivered as a series of instructions in binary format to Flash Player over web protocols in the precisely described SWF (.swf) file format (described at http://www.adobe.com/licensing/developer/). The SWF files themselves are typically hosted on a server and then downloaded to, and displayed on, the client computer when requested. SWF files consist of multimedia content (vectors, bitmaps, sound, and video) and binary ActionScript instructions. ActionScript is the ECMA standards-based scripting language used by Flash that features APIs designed to allow the creation and manipulation of client-side user interface elements, and for working with data. Flash Player is designed to allow all SWF file content to be viewable and available consistently across a broad range of platforms, browsers, and devices. Flash Player is also designed to provide a robust environment to ensure security and privacy for the author, user, host institutions, and any of their respective data. Adobe Flash Player 9 Security 2 The Flash Player security environment The Flash Player client runtime security model has been designed around resources, which are objects such as SWF files, local data, and Internet URLs. Stakeholders are the parties who own or use those resources. This document has been organized to reinforce that model. Within the Flash Player security model, each stakeholder can exercise controls (security settings) over their own resources, and each resource has four stakeholders. Flash Player strictly enforces a hierarchy of authority for these controls, as the following figure shows: Figure 1: Hierarchy of security controls Administrator (User Institution) settings User settings Website settings Author settings This means, for instance, that if an administrator restricts access to a resource, no other stakeholders can override that restriction. In Flash Player, it is common for multiple stakeholders to have the ability to control access to a resource, and for some stakeholders to formally delegate the right of control to a lower level in the hierarchy. For example, Administrators regularly allow users to make security decisions about their own environment. The following sections describe these stakeholders. Adobe Flash Player 9 Security 3 Stakeholders In any computer system, there are multiple stakeholders (individuals or classes of individuals) with interests related to correct operation and the protection of their data and resources. This is particularly important in an environment in which a user may obtain code from multiple sources (such as Flash Player from Adobe and a SWF file from another source), plus data from an outside website, in order to run an application on their local computer. The following stakeholders may have security or privacy interests in this environment: • Administrative user and the user institution • User • Website owner • Author Administrative user (of a particular client computer) and the user institution A client computer has administrative settings that can only be modified by administrative users, as determined by the user institution, which is the entity on whose behalf the computer is used. The administrative user may simply be the user (in an in-home usage), but in work environments this can be restricted to administrators in an IT department. Such an institution typically owns and administers the computer (to varying extents). In some cases, each user may have multiple user institutions, as when an independent contractor contracts with multiple user institutions while using one computer. An institution may have data and configuration information on that computer (or on internal networks available to that computer) that it wants to protect from corruption or theft by programs that the user may select, install, or execute. Both users and user institutions are likely to have data on the client computers that they do not want shared on the external network. User (of a particular computer and programs) The user is the single end-user consumer running Adobe and third-party products and applications on a client computer. Modern operating systems partition the computer to provide a degree of protection between multiple users of a single personal computer, and to a minor extent between programs running simultaneously on behalf of a single user on the same computer. It is possible that more than one user might use the same computer, or that one user may have multiple applications running and not want data shared between them. Privacy protection is considered one aspect of the security goals. Website owner Websites hosting Flash applications rely on Flash Player behavior to deliver their content and application features. Website (and their data) owners also implement security measures such as authentication, access controls, and network firewalls to ensure the integrity of their website. It is also important to distinguish between internal websites (behind one or more firewalls common to the client computer) and external websites (the rest of the Internet world). Users often access external websites as part of doing company business, and Flash programs from such external sites must not compromise security, such as unintended exposure of data from the user’s local (intranet) data back to the external website, nor from the external website to the user. Author (of a Flash application) An author is the program developer and publisher of a Flash application. The author might want to protect code (and data) from unauthorized modification or use. Protecting a Flash application means providing an environment in which the program can continue to work correctly (and be affected by only those things it chooses to be affected by), keep secret all of its logic and state but that which it chooses to reveal, and impose proper security policies on its components. Adobe Flash Player 9 Security 4 Overview of permission controls The Flash security architecture provides each stakeholder with a set of permission controls for controlling access to their assets. The following table provides an overview. For more information, see “Permission Controls” on page 19. Table 1: Stakeholder permission controls Stakeholder Control Description Administrator The mms.cfg file The mms.cfg file, accessible only to an administrative user, controls security-related Flash Player settings for the client computer, including the following: User ƒ Access to any camera or audio input devices attached to the computer ƒ Global control of local file reading, as well as file upload and download capabilities ƒ Local Flash Player disk usage and third-party storage of persistent shared objects ƒ The ability of users to permit content to use older security models ƒ Flash Player auto-update settings Global Trust files When installing a Flash application to a client computer, an installer (run by an administrator) can establish specified local files and directories as being trusted. Settings Manager Settings UI Flash Player includes a Settings Manager that lets the user set the security-related options (for that specific user of the computer), such as the following: Dialog Boxes ƒ Access to any camera or audio input devices attached to the computer ƒ Local Flash Player disk usage and third-party storage of persistent shared objects ƒ Flash Player auto-update settings When legacy content (content built for an earlier version of Flash Player) attempts to access resources that are protected in the new version of Flash Player, Flash Player presents warning messages to the user. Website User Trust files When installing a Flash application to a client computer, the installer (run by a specific user of the computer) can establish specific local files and directories as being trusted (for that user). Cross-domain policy files Website administrators can use these files to control Flash applications’ access to resources on the domain. Adobe Flash Player 9 Security 5 Stakeholder Control Description Author Cross-script APIs and access to data originating from domains other than that of the SWF file Flash Player provides a number of API calls related to security. For more information, see “Developer controls” on page 31. Sources for potential risk It is also useful to categorize those sources of potential risk that the Adobe Flash platform protects stakeholders against. These include sources that can result from both malicious and accidental actions by other stakeholders or third parties. Innocent bugs When a piece of software is part of a much larger system, it is a good practice to conceptualize software as being surrounded by malevolent entities, even when it is not. Design and implementation bugs can lead to security holes that can be exploited by malevolent entities, or simply can lead to unexpected (unwanted) behavior of the program. The most common security vulnerabilities are the result of innocent bugs, and Flash Player is designed to prevent introduction of a wide variety of these bugs, such as buffer overflows and cross-site scripting. Other stakeholders Other users and user institutions with access to the same system are also entities to be protected against. They might want to obtain access to data that is not intended for sharing in those circumstances. Flash Player provides a clearly articulated model for sharing information: by default, Flash applications may not inspect or modify data without explicit permission from a stakeholder of that resource. Internet providers While Internet providers might not intend to be potential sources of risk, they provide services that are vulnerable to certain classes of attacks. Internet providers include backbone operators, with significant responsibility for the correct functioning of DNS and packet routing. Adobe Flash Player 9 Security 6 Flash Player security claims This paper focuses on security related to Flash Player. Flash Player executes on the client’s computer to view Flash content, typically from a host web server. It protects all stakeholders against three broad classes of potential security breaches: • Unauthorized access to data. This data could be on local disks, networked disks, or web servers that are communicated with over the network or stored in memory by an application or process. (Examples might include password lists, address books, protected documents, and application code.) • Unauthorized access to end-user information. This includes personal and financial data, among other information that might be on the end user’s computer. This also includes information about the enduser’s security settings for Flash Player. • Unauthorized access to host system resources. This includes gaining control of applications, devices, or resources attached to the system for the purposes of disabling, or denying or redirecting access, to those resources. (Examples might include buffer overruns and denial of service attacks.) Overall, Flash Player provides very controlled and selective access to other resources. The functionality available to Flash application developers is a small, constrained subset of the functionality that could potentially allow exposures. For example, Flash Player does not allow content to inspect directories of local file systems, erase or modify arbitrary local files, shut down the user’s computer, or make changes to the operating system. Because the system functionality that Flash Player (or its applications) can access is carefully limited, the risk of creating content that could gain unauthorized access to the host system or resources attached to it is minimized. Adobe Flash Player 9 Security 7 New Security Features in Flash Player 9 Although the basic security model remains the same as in previous versions of Flash Player, Flash Player 9 includes a number of new security features over previous versions. Many security enhancements result from the introduction of the new ActionScript 3.0 language (and the AVM2 virtual machine) in Flash Player 9: • The ActionScript 3.0 display list—This new architecture for working with onscreen objects provides more efficient code for checking the security restrictions for content loaded from different domains. • Greater restriction of cross-domain visual and sound elements—New restrictions prevent (by default) SWF files from different domains inappropriately overlaying visual content in an application or from inappropriately stopping audio. • Import loading of SWF files—When loading another SWF file, a loading SWF file can request that Flash Player check for a cross-domain policy file on the loaded file’s server, and if granted permission, the loading SWF file can access the loaded content with the same access as if it were loaded from the domain of the loading file. • Access to sound data—ActionScript 3.0 provides greater access to the data in loaded sound (MP3) files, such as sound spectrum data. Cross-domain access to this data is controlled via cross-domain policy files. • Better default location for cross-domain policy files—In ActionScript 3.0, the default source for a crossdomain policy file pertaining to socket connections is the same port as the socket (rather than an HTTP server). • Restricted access to media data originating from RTMP servers—Flash Player 9 cannot access video data or sound spectrum data for media loaded from RTMP (Flash Media Server) sources, although it can display and play video and sounds loaded from these servers. • Improved scope of permission mechanisms—Flash Player 9 provides more specific control when using the Security.allowDomain() and Security.exactSettings APIs than was available in previous versions. In Flash Player 9, using these APIs applies only to the SWF file that calls them, not to other SWF files from the same domain. • The allowNetworking flag—A new HTML setting provides greater control of networking capabilities of SWF files. Adobe Flash Player 9 Security 8 Flash Player security architecture The Flash Player client runtime provides a comprehensive security architecture that defines the permissions granted to SWF files. Generally, these permissions are of the type read or send. Permissions are granted to a SWF file by the administrative user, end user, or website based on the origin of that SWF file. Authors may also grant permissions to specific SWF files. Basic sandbox security model A significant component of security in Flash Player is based on sandboxes, which are logical security groupings that Flash Player uses to contain resources. Flash Player uses these security sandboxes to define the range of data and operations that each Flash application may access—that is what resources can be accessed. Everything within each sandbox is securely controlled by stakeholders of that sandbox. This includes file requests, local data storage (shared objects), and any other resources used by a particular domain and its content. Each sandbox is isolated from the operating system, file system, network, other applications, and even other Flash Player sandbox instances. Flash Player assigns SWF files to sandboxes based on their origin. Flash Player bases sandbox boundaries on Internet domains or, for local SWF files, on the class of local SWF file. As described earlier, Flash Player always runs SWF files from the Internet in separate sandboxes that correspond to their origin domains. Flash Player places SWF files from local origins (local file systems or UNC—universal naming convention— network paths) into one of three specific sandboxes for local SWF files only. Security enhancements in Flash Player 8 and later differentiate between more sandboxes than were available in earlier versions. Any two SWF files that run in the same sandbox may interact freely with each other (for example, two SWF files downloaded from the same network domain). SWF files may also interact with SWF files from other sandboxes (and with servers), but only in accordance with specific security rules and configuration settings, which are described in “Permission Controls” on page 19. An author of a SWF file can use the ActionScript Security.sandboxType property (System.security.sandboxType in ActionScript 1 and 2) to determine the type of sandbox to which Flash Player has assigned the SWF file (for more information, see "Security.sandboxType" on page 35). Flash Player places files, shared objects, and other resources in sandboxes corresponding to their origin domain. Figure 2: Flash defines sandboxes based on source domains Adobe Flash Player 9 Security 9 Domain of origin Flash Player gets domain information from the host application (such as a browser). That information is only as reliable as the underlying protocol. For example, HTTP uses DNS for domain information, which is subject to spoofing; HTTPS uses SSL (secure socket layer) certificates, which provide cryptographically verified domain information. Flash Player applies a set of rules to the URL information it receives from the host application to determine if the content is from a local source. Prior to Flash Player 7, the cross-domain security decisions were made on the basis of a superdomain comparison, to attempt to accommodate SWF files from similar domains (for example, www.adobe.com and store.adobe.com) to communicate freely with each other (and with other documents). However, security weaknesses could stem from a policy this broad. The Exact Domain Match feature of Flash Player 7 strengthened the domain-matching behavior, requiring that network SWF files can only communicate freely with each other (and with other documents) when they come from the same domain. Besides being much more secure, this also more closely matches the behavior of models used by DHTML and Java on the client. By default, content loaded with a protocol other than HTTPS cannot access content that was loaded with HTTPS, even if from the same domain. The reverse direction is allowed; HTTPS content may access content loaded with other protocols from the same domain. Default permissions In the following series of diagrams, the arrows illustrate types of access: • A solid arrow drawn between a SWF file and a non-SWF file resource depicts a read operation where the SWF file at the tail of the arrow is making the request on the resource indicated by the head of the arrow. The read access of a data resource outside of Flash Player is often referred to as data loading, because data is being brought into Flash Player for use by a SWF file. A solid arrow may also be drawn between two SWF files to depict a read permission. This may be described as a cross-scripting, because the SWF file at the tail of the arrow may invoke functions in the SWF file indicated by the head of the arrow. (Cross-scripting is not possible between AVM1 SWF files, which use ActionScript 1.0 or 2.0, and AVM2 SWF files, which use ActionScript 3.0.) • A dashed arrow indicates data sent from the SWF file at the tail of the arrow and handled by the object indicated by the head of the arrow. Figure 3: A read request from a SWF file to another resource request Figure 4: A message sent from a SWF file to another resource send From the a.com sandbox, a SWF file may read (using the ActionScript URLLoader.load() method, for example) from the server at a.com (but cannot by default read from b.com), and may send anywhere on the network. Any two SWF files in the same sandbox may interact freely with each other. Diagrams in later sections explain how SWF files may interact with SWF files from other sandboxes, and with servers. Adobe Flash Player 9 Security 10 Figure 5: Default sandbox permissions Adobe Flash Player 9 Security 11 Accessing data in another sandbox In order for a SWF file to read data in another sandbox, it must be granted explicit permission by stakeholders of that other sandbox. There is a well-defined chain of precedence such that each stakeholder can protect the assets within their domain or system from external access. As detailed in “The Flash Player security environment” on page 3, the following have authority to grant access to files, and the precedence of control is in the order of this list: • User institution administrators • Users • Website administrators • Flash application authors In other words, user institution administrator decisions take priority over user decisions, which take priority over website administrator decisions, which take priority over Flash application author decisions. This should not be taken to imply that all decisions about permissions can be enforced or modified by all stakeholders, because that is not true. For example, using ActionScript to communicate directly with another SWF file requires the read permission. Only the author can grant read permission for cross-scripting by calling the Security.allowDomain() method. Similarly, the send permission is generally allowed between sandboxes because the recipient is expected to handle the information in a secure manner. In some places where a security exposure might result from sending, the Flash Player runtime may restrict this functionality, unless explicit permission is provided. Figure 6: Read across sandbox boundaries is strictly controlled Administrative users, users, website administrators, and developers can grant permissions that are not available by default to SWF files (see “Permission Controls” on page 19). A SWF file from a.com may read from the server at b.com (using the ActionScript URLLoader.load() method, for example) if b.com has a cross-domain policy file that permits access from a.com (or from all domains). A SWF file from a.com may cross-script a SWF file from b.com (calling an ActionScript method in the b.com SWF file, for example) if the b.com SWF file calls the ActionScript Security.allowDomain() method to permit access from a.com. Adobe Flash Player 9 Security 12 Permissions for specific domains Network files All resources in a network sandbox follow the basic sandbox model. Each domain is given its own sandbox. (For more information, see “Basic sandbox security model” on page 9.) Local files Local files also follow the basic sandbox model, with this exception: they have different default permissions. There are three different sandboxes for local files: • local-with-filesystem • local-with-networking • local-trusted. For more information on these sandboxes, see “Basic sandbox security model” on page 9. Local SWF files may be placed in the local-with-networking sandbox by virtue of a developer control (see “Options when publishing” on page 37). Local SWF files may be placed in the local-trusted sandbox by virtue of various administrative or user controls (see “Flash Player Trust directories and files” on page 29 and “Global Flash Player Trust directory” on page 22). Local SWF files, by default, are placed in the local-with-file-system sandbox and may read from files on local file systems, but they may not communicate with the network, except in instances where the network resource is considered a local file. By default, network SWF files may not cross-script local SWF files. However, authors can grant permissions for network SWF files to cross-script local SWF files in the local-with-networking sandbox or local-trusted sandbox by using the ActionScript Security.allowDomain() method. A local SWF file in the local-with-file-system sandbox is not allowed to grant such permissions, because this would make it possible for the local SWF file and a network SWF file to cooperate in reading data from a local file system and sending the data to a web server. Adobe Flash Player 9 Security 13 The following diagram shows the unrestricted permissions granted to local-trusted SWF files: Figure 7: Default permissions for a SWF file in the local-trusted sandbox Local-trusted SWF files may read from local files; read or send messages with any server; and script any other SWF file. The following diagram shows the default permissions available to local SWF files in the local-with-filesystem sandbox. These SWF files are not granted access to any network resource, as are files in the localtrusted sandbox, so they cannot be granted access directly to any network resource. Figure 8: Default permissions for local-with-file-system SWF files; these cannot be modified Adobe Flash Player 9 Security 14 The following diagram shows the default permissions available to local SWF files in the local-withnetworking sandbox. These SWF files are not granted permissions available to the local-trusted sandbox, but they do have default access to send to the network. Also, they can be granted read access to network sandboxes. Figure 9: Default permissions for local-with-networking SWF files In the absence of permissions, local-with-networking SWF files are only allowed to communicate with other local-with-networking SWF files and to send to network servers. A local-with-networking SWF file is allowed to read (using the ActionScript URLLoader.load() method, for example) from the server at a.com if a.com has a policy file that permits access from all domains. A local-with-networking SWF file is allowed to cross-script a SWF file from a.com (calling an ActionScript method in the a.com SWF file, for example) if the a.com SWF file calls the ActionScript Security.allowDomain() method to permit access from all domains. Similarly, a local-with-networking SWF file is allowed to cross-script a local-trusted SWF file if the local-trusted SWF file calls the ActionScript Security.allowDomain() method for all domains. Developers can grant permissions to local-with-networking SWF files by granting permissions to all domains. The all-domains requirement reminds developers and server administrators that allowing access by local-with-networking SWF files is equivalent to allowing access by anyone, because Flash Player cannot determine the origin of a local-with-networking SWF file. Developers can never grant permission to allow local-with-networking SWF files to read from local files. Using permissions, local-with-networking SWF files can be made completely interoperable with network SWF files and servers. Permissions also make it possible for local-trusted SWF files and network resources to communicate freely. However, even with the maximal set of permissions, data cannot flow from local file systems to the network without going through a local-trusted SWF file. Adobe Flash Player 9 Security 15 Interpreters and byte code Flash Player includes a virtual machine to run instructions that are contained in the byte code of a SWF file. Those familiar with earlier versions of Flash Player (which used the original AVM) and other implementations (such as the Java virtual machine) need to be aware of significant potential differences in this area with Flash Player 9. With Flash Player 9, when using ActionScript 3.0 and AVM2, there is an entirely new byte code instruction set and a new approach to byte code execution. The new byte code instruction set provides faster execution and type safety. The AVM2 byte codes are geared for recompilation to machine code (known as JIT or just-in-time compilation). Because Flash Player 9 includes both AVM2 and the older AVM, it can run applications written in ActionScript 3.0 and, for backward compatibility, ActionScript 1.0 and ActionScript 2.0. The following sections discuss factors in common for all versions, and also highlight the significant differences possible in Flash Player 9 with ActionScript 3.0 and AVM2. Background A common type of virtual machine construct is a program that interprets another program written in a particular language. This is in contrast to a somewhat different concept of a virtual machine that subdivides a real machine so as to provide the illusion of several concurrently running similar machines. These two technologies have many attributes in common, but this discussion concerns the first case, a virtual machine that runs within a traditional operating system and interprets programs written in a specific interpretive language (such as Java, JavaScript, ActionScript, Python, Perl, SmallTalk, or TCL). These languages typically have interpreters that run within several operating systems to support common applications across a broad spectrum of computers. Java was perhaps the first to emphasize limitations that the interpreter placed on the programs that it interpreted. As both Java and web browsers grew in popularity, it became strategic to limit the actions that a program could take in the context of a browser fetching a Java program within a web page. For example, a Java program cannot delete (or even read) any local files on the user’s computer. The Java program is at least partially constrained and said to run within a Java sandbox. Similarly, JavaScript, which is only distantly related to Java, also travels from a website to the user’s computer to be interpreted by software typically included in the browser. This interpretation similarly limits the actions that a JavaScript program can take. Usually, Java arrives at the browser as byte codes in a .class file, and JavaScript arrives at the browser embedded in HTML files. ActionScript is closely related to JavaScript as a language, but delivers its code to the client’s computer in the form of a SWF file (with a .swf extension), which can also carry data, such as audiovisual content. The Flash Player client runtime then synchronizes the execution of the ActionScript code with the audiovisual content. The ActionScript code can also augment and override the simple audiovisual content. The Flash authoring tools transform Flash applications completely to a byte code representation on the developer’s computer (in the debugging cycle or when publishing). These byte codes are then transmitted from the website to the client computers in a SWF file (or projector file). The Flash Player AVM therefore is only an interpreter of byte codes (rather than of ActionScript), and byte codes are significantly smaller and faster to interpret. With ActionScript 2.0, authors are allowed (and encouraged) to declare the types of values that variables and parameters will use, meaning that the byte codes will have types that can be known before the program begins to run. This helps reduce potential development bugs. Adobe Flash Player 9 Security 16 ActionScript is therefore only delivered to the client’s computer in the form of byte codes. The byte codes are for a stack-based virtual machine, so the meaning or validity of a particular byte code depends on the state of the stack as the code is encountered during interpretation. In a stack-oriented example, an add operation replaces the top two values on the value stack with their sum, after which the stack has one less value. There is also a control stack upon which is pushed the byte code cursor when a subroutine byte code is encountered. The subroutine finds its arguments on the value stack and places any return results there, and then returns by consuming the top element of the control stack. Byte code verification is done in the client’s computer (by the Verifier) and consists of determining the types that each byte code will consume and produce, by forming a map of the types of the values on the value stack for each byte code. Therefore, byte code programs that use invalid byte codes (given their operand types) can be detected and rejected early. This eliminates some runtime checking that would otherwise be necessary for system integrity. ActionScript 3.0 goes further at this point and produces native machine instructions to perform the actions of the program, having assured itself of the types of the values it will obtain as the program runs. This translation to native instructions depends mainly on knowledge that byte code verification must generate as it proceeds. Although this process is fairly complex, it is also well defined and it is clear what the interpreter would do under the conditions that the Verifier has proven will occur. Therefore, it is relatively direct for AVM2 to map these to the appropriate machine instructions. Code isolation A Flash application can potentially express actions that do any of the following: • Read files • Make connections over the network interface • Contact other SWF files Each of these operations is, in fact, ultimately performed by routines included in and controlled by the native (Adobe) Flash Player code (not by any third-party or application code), and then only after checking and enforcing all applicable access policies as established by the security model and the current runtime security controls. This is true for all versions of Flash Player, although there are some new differences in the granularity and implementation of the access control rules in Flash Player 9 (discussed in other sections of this document). Additionally, the byte codes are isolated, non-native code that cannot execute on the user’s local processor. This constraint further ensures that Flash application code (SWF files) cannot affect other programs or data on the same computer. The only machine instructions executed as a result of running an ActionScript program with Flash Player are those instructions that are part of Flash Player itself (as signed and distributed by Adobe) and those instructions produced by Flash Player by its translation of the byte codes of the SWF file (and these only after verifying compatibility of such instructions with the data types produced by preceding instructions, and applying Flash Player security policies). Adobe Flash Player 9 Security 17 Disk, memory, and processor protections Flash Player includes security protections for disk data and memory usage on the client computer. Disk storage protections The only type of persistent storage is through shared objects, which are embodied as files in directories whose names are related to that of the specific owning SWF files. An ActionScript program cannot write, modify, or delete any files on the client computer other than shared objects, and it can only access shared objects under the established settings per domain. There are no primitives (no mechanisms) available to Flash applications that can read, create, modify, or delete directories or files. Shared objects are therefore normally associated with a given SWF file’s particular domain and sandbox. They actually use a finer-grained model than the usual concept of a sandbox, so that they are (by default) associated with an individual SWF file within the sandbox. An author can create shared objects, however, to cover the scope of an entire sandbox by providing a (non-default) “localPath” when creating them. The file path to the shared object data contains pseudo-random data so that the storage is not in a predictable location. Flash Player can also store shared object data loaded from HTTP and HTTPS paths in separate locations. So a movie loaded by HTTPS can specify that its shared objects cannot be accessed by a movie loaded via HTTP, even if the URL is the same otherwise. Flash Player helps limit potential denial-of-service attacks involving disk space. Disk space is conserved through limits automatically set by Flash Player (the default is 100K of disk space for each domain). Capabilities exist for the author to include the ability for the Flash application to prompt the user for more, or Flash Player automatically prompts the user if an attempt is made to store data that exceeds the limit. In either case, the disk space limit is enforced by Flash Player until the user gives explicit permission for an increased allotment for that domain. A Flash Player user interface lets the user set persistent disk storage allocation settings (per domain) that limit the use (amount) of permanent disk storage by the Flash applications within that domain. The user can also indicate a global setting for how much disk storage any new Flash applications (from domains not yet individually specified) can use. (For more information, see “Storage settings” on page 27.) Memory usage protections and processor quotas Flash Player contains memory and processor safeguards that help prevent Flash applications from taking control of excess system resources for an indefinite period of time. For example, Flash Player can detect an application that is “stuck” in a script for more than 15 seconds (possibly because it is running an infinite loop) and select it for termination by prompting the user. The resources used by the application are immediately released when the application closes. Flash Player 9 uses a garbage collector engine common to other Adobe products. The processing of new allocation requests always first ensures that memory has been cleared so that the new usage always obtains only clean memory and cannot view any prior data. Adobe Flash Player 9 Security 18 The Verifier In prior versions of AVM (ActionScript code), the Flash Player AVM did all the verification dynamically. For Flash Player 9 using AVM2 (byte codes), the Verifier does all the checks. The Verifier handles descriptions of classes and types, mapping of bindings, and so on. The Verifier both checks that the code is complete and valid, and provides some optimizations of the code (such as elimination of null checks at runtime). The Verifier checks all code loaded into the virtual machine; for example, the Verifier can throw error exceptions that user code can handle, but anything re-introduced is then re-verified. Adobe Flash Player 9 Security 19 Permission controls The range of stakeholders and differences in their perspectives over security and privacy issues requires a layered approach to the specification (and checking) of access controls. Flash Player offers a range of configuration mechanisms to address corporate security policy issues and user privacy concerns without significantly reducing the key benefits of Flash Player. The chosen options (and defaults) in the configuration files, along with the overall Flash Player security model and other administrator, developer, user, and default options, may make Flash Player more secure than an individual stakeholder desires with respect to local files and local shared files, but should not be less secure. This may also mean that some new restrictions are enforced on some legacy applications when they are executed in Flash Player 9. Some security control features in Flash Player target user choices, and some target the modern corporate and enterprise environments, such as when the IT department would like to install Flash Player across the enterprise but has concerns about IT security and privacy. To help address these types of requirements, Flash Player 9 provides various installation-time configuration choices (some new). For example, some organizations do not want Flash Player to have access to the computer’s audio and video hardware; other environments do not want Flash Player to have any read or write access to the local file system. For a table with descriptions of permission controls, see “Overview of permission controls” on page 5. Administrative user controls The system administrator of the internal network (where users may execute Flash applications) can designate rules about Flash Player options and Flash application access with the mms.cfg file and Global Flash Player Trust files. The mms.cfg file The primary purpose for the mms.cfg file is to support the corporate and enterprise environments where the IT department would like to install Flash Player across the enterprise, while enforcing some common global security and privacy settings (supported with installation-time configuration choices). On operating systems that support the concept of user security levels, the file is flagged as requiring system administrator (or root) permissions to modify or delete it. On Mac OS X systems using mms.cfg, the security configuration file is located at /Library/Application Support/Macromedia/mms.cfg. On Microsoft Windows, the file is located in the Flash Player folder within the system directory (for example, C:\windows\system32\macromed\flash\mms.cfg on a default Windows XP installation). When Flash Player starts, it reads its security settings from this file, and uses them to limit or change functionality. The types of controls included in the mms.cfg file include: • Data Loading Controls—Settings in this category permit administrators to prevent reading of local files (which is only ever permitted for local SWF files); prevent uploading and downloading of files between remote servers and local file systems (which is permitted by default, but is always subject to user approval); and limit (optionally to zero) the amount of local storage that websites may use for shared objects. Adobe Flash Player 9 Security 20 • Privacy Controls—Settings in this category permit administrators to disable the reading and writing of persistent data by third-party SWF files (those whose domains don’t match the URL shown in the browser’s address bar); disable the use of camera and microphone devices to capture video and audio streams (which is permitted by default, but is always subject to user approval using dialogs); and disable the enumeration of system fonts installed on a user’s computer. • Update Controls—Settings in this category permit administrators to configure the self-updating mechanism used by Flash Player. Administrators may disable auto-update entirely; increase or decrease the frequency of checks for newer versions; and specify an alternate location from which to download updates (the default location is an Adobe server on the Internet). • Legacy Controls—As security has improved over the history of Flash Player, certain rules have been changed from one major version to another. This has occasionally caused existing Flash applications to stop functioning as originally intended, because some SWF files were inadvertently depending on Flash Player behavior that was deemed risky and phased out. When Flash Player detects that a SWF file is attempting an operation that would have been permitted in an earlier version of Flash Player, but is no longer permitted, Flash Player notifies the user of the discrepancy, partly as an explanation of why the application may not function correctly, and partly as an alert to the user that, if they believe that the malfunctioning application is from a trustworthy source, they can opt to permit the older, less secure behavior in order to allow the application to work as intended. Settings in this category of mms.cfg permit administrators to force the newer, more secure rules to be used at all times, which also disables the warning messages to users. Flash applications using the older rules will simply malfunction until their maintainers repair them. Administrators can also specify that certain older behaviors are always permitted for older Flash applications, which may be helpful, for example, if an organization maintains inhouse Flash applications that depend on the older security rules. • Local File Security Controls—Settings in this category permit administrators to prevent users from designating SWF files on local file systems as trusted (thus electing those SWF files into the localtrusted sandbox). This affects two mechanisms by which users can ordinarily designate trust: interactively, using the Settings Manager, and through the use of user trust files, which are typically employed by installer applications that run without administrative rights. Details on the mms.cfg file settings are available at www.adobe.com/go/fp9_admin. The mms.cfg affects the options in the Flash Player Settings dialog box, and some mms.cfg file settings may override individual settings. The Settings dialog box has four tabs: • Privacy—If the AVHardwareDisable mms.cfg setting is set to true, all user actions related to this tab are ignored. The tab does, however, appear functional. • Local Storage—If the LocalStorageLimit mms.cfg setting is set, this tab shows the limit specified in that option. However, the user can use this tab as if the limit does not exist. If the user selects settings higher than the limit set in the configuration file, the user’s settings are ignored. If the user sets more restrictive settings, they are honored (and displayed the next time the Settings dialog box is invoked). The local file storage limit is best obtained from the Settings dialog box, because this security setting is just a maximum value, and the user may have set a lower limit. • Microphone—If the AVHardwareDisable mms.cfg setting is set to true, the recording level meter is disabled. All other controls appear to work, but their values are ignored. • Camera—If the AVHardwareDisable mms.cfg setting is set to true, clicking the camera tab does not bring up a thumbnail of what the camera is seeing. Adobe Flash Player 9 Security 21 Flash authors can query the Capabilities.avHardwareDisable and Capabilities.localFileReadDisable properties to change the behavior of their Flash applications based on features disabled by security; however, they cannot modify those values. Authors should be familiar with the range of information (such as pixel aspect ratio, screen size, color support, and so on) available with the Capabilities class (all properties of this object are read-only). For additional information on the Capabilities class, see the ActionScript 3.0 Language Reference. Global Flash Player Trust directory Local files are only placed in the local-trusted sandbox at the direction of a user, an administrative user, or an installer program. Administrative users, and installer programs that are run with administrative rights, have the option of designating trust by creating configuration files in a directory called the Global Flash Player Trust directory. Flash Player reads all configuration files in this directory; the configuration files may have any names, but the recommended convention is to use the extension ".cfg", and choose a filename that describes the files being trusted, so as to avoid name collisions. Each line of each configuration file lists a local path that is to be trusted. These paths may name individual files or entire directories. If a directory specified, the directory and all of its descendant directories are trusted. Configuration files in the Global Flash Player Trust directory affect all users of the computer. The Global Flash Player Trust directory is alongside the mms.cfg file (the system configuration file discussed in the previous section), in the following location, which requires administrator access: • Windows: system\Macromed\Flash\FlashPlayerTrust (for example, C:\windows\system32\Macromed\Flash\FlashPlayerTrust on a default Windows XP installation) • Mac: app support/Macromedia/FlashPlayerTrust (for example, /Library/Application Support/Macromedia/FlashPlayerTrust) There are also individual User Flash Player Trust directories, used by installers to register an application for specific users of a computer (see “Flash Player Trust directories and files” on page 29). The Global and User Flash Player Trust directories have different security precedence in relation to each other and to settings in the mms.cfg file (see “Hierarchy of local file security controls” on page 38). Depending on whether Flash Player will be embedded in a non-browser application, one of two strategies may be appropriate: register SWF files and HTML files to be trusted, or register applications to be trusted. Only applications that embed the browser plug-ins can be trusted—the stand-alone players and standard browsers do not check to see if they have been trusted. Adobe Flash Player 9 Security 22 User controls Flash Player provides users with four different mechanisms for setting permissions. The Settings UI provides a quick, interactive mechanism for configuring the settings for a the domain of a SWF file being displayed. The Settings Manager presents a more detailed interface than the settings UI and provides the ability to make global changes that affect permissions for many or all domains. Additionally, at the moment a new permission is requested by a SWF file, requiring runtime decisions concerning security or privacy, Flash Player presents dialog boxes that allow users to adjust some Flash Player settings. Also, users can set permissions for specific applications in the Flash Player Trust directory. In the case of the Settings Manager, although it appears that these settings are configured within the context of a web page, Flash Player actually retrieves the settings locally and only displays them in the apparent context of the web page being viewed. Adobe does not collect any information about Flash Player user settings or preferences, and at no time are the user’s settings transmitted off of the user’s computer. The Settings Manager appears to be an application hosted on the Adobe web page (www.adobe.com), but it is in reality a SWF file served from the Adobe domain and running on the user machine. Although the Settings user interface (UI) and the small context-sensitive runtime Settings dialog boxes appear superimposed over other Flash Player content, Flash Player runs these in separate sandboxes. Settings Manager The Settings Manager allows the individual user to specify various security, privacy, and resource usage settings for Flash applications executing on their client computer. For example, the user can control application access to select facilities (such as their camera and microphone), or control the amount of disk space allotted to a SWF file’s domain. The settings it manages are persistent and controlled by the user. The user can indicate their personal choices for their Flash Player settings in a number of areas, either globally (for Flash Player itself and all Flash applications) or specifically (applying to specific domains only). To designate choices, the user can select from the six tab categories along the top of the Settings Manager dialog box: • Global Privacy Settings • Global Storage Settings • Global Security Settings • Flash Player Update Settings • Privacy Settings for Individual Websites • Storage Settings for Individual Websites You can view the Settings Manager at: http://www.adobe.com/support/documentation/en/flashplayer/help/settings_manager.html Adobe Flash Player 9 Security 23 The following figures show samples of the Settings Manager. Figure 10: Global Privacy Settings tab Figure 11: Global Storage Settings tab Figure 12: Global Security Settings tab Adobe Flash Player 9 Security 24 Figure 13: Global Notification Settings tab Figure 14: Individual Website Privacy Settings tab Figure 15: Individual Website Storage Settings tab Adobe Flash Player 9 Security 25 Figure 16: Global Security Settings tab All of the settings information managed by the Settings Manager is retained in persistent Flash Player data that cannot be accessed via ActionScript. These objects are accessed only to modify the settings on the local machine in direct response to a user request through the Settings Manager. The content is not reviewed by Adobe, nor is it transmitted across the network. Settings UI and runtime dialog boxes These settings are most commonly accessed by right-clicking (or, on the Macintosh, Shift-clicking) an executing SWF file and selecting the Settings option. The Settings UI provides users with the ability to modify settings and security controls for the domain of the main SWF file running in the player while the Settings UI is displayed, and it also provides an access point to the Settings Manager by using the Advanced button on the Privacy tab. Flash Player tries to minimize any exposure of security decisions to end users. However, some runtime behavior may require user intervention or approval, such as for privacy-related issues (cameras and microphones), or when older applications attempt access that is no longer permitted by default. If the application is too small to display the Settings UI or a runtime dialog box (the minimum size is 215 x 138 pixels), the Settings context menu item is disabled, and if user approval of an action is required, Flash Player, by default, treats the operation as if Deny were selected. Privacy settings An interface lets the user set persistent privacy settings per domain that control access by Flash applications to the system’s camera and microphone. The default is to ask the user, and Flash Player denies access to the camera and microphone if the user does not explicitly grant access. Figure 17: Privacy settings Adobe Flash Player 9 Security 26 Camera settings An interface lets the user set camera information. This panel does not have direct security or privacy implication. Use the privacy settings to control whether the camera is accessible to Flash applications. Figure 18: Camera information Microphone settings An interface lets the user set microphone configuration. This panel does not have direct security or privacy implication. Use the Privacy Settings to control whether the microphone is accessible to Flash applications. Figure 19: Microphone settings Storage settings Users can also set storage limits for all Flash applications from the current domain using the following UI. Setting the storage to 0 kilobytes causes Flash Player to prompt the user if a Flash application requests a shared object. In this case, if the user selects the Never Ask Again option, Flash Player forbids storage by the current domain. Figure 20: Individual Flash application storage settings Adobe Flash Player 9 Security 27 Domain match and HTTP/HTTPS warnings One (or both) of the following screens may appear for users when they run an older (Flash Player 6 or earlier) application that makes a data loading request forbidden in current versions of Flash Player, but which would have been permitted in Flash Player 6. The dialog box on the left is an example for a request that was acceptable due to the similarity of the domain names. The dialog box on the right is an example of a request from an insecure (HTTP) site to a secure (HTTPS) site. Figure 21: Fallback access warnings If the user clicks Allow, the request succeeds. If the user clicks Deny, the request fails. The dialog boxes do not appear if at some time previously the user selected the Never Ask Again check box. Network Access Warning The following dialog box is directed at users if they attempt to run an untrusted local SWF file (in the localwith-file-system sandbox) that tries to access the network. The dialog box only appears for operations that would have succeeded in Flash Player 7 or earlier, and are undertaken by SWF files that were produced for versions of Flash Player prior to Flash Player 8. The dialog box appears no more than one time for each time the player is executed. Also, it does not appear if either the administrator or user options have been set to request silent failures. Authors cannot disable this by requesting silent failures or successes; authors must either avoid such prohibited actions or the dialog box appears based on user and administrative controls. Figure 22: Network access warning Adobe Flash Player 9 Security 28 Flash Player Trust directories and files The User Flash Player Trust directory is alongside the Flash shared objects storage area, in the following locations (which are specific to the current user): • Windows: app data\Macromedia\Flash Player\#Security\FlashPlayerTrust (for example, C:\Documents and Settings\JohnD\Application Data\Macromedia\ Flash Player\#Security\FlashPlayerTrust) • Mac: app data/Macromedia/Flash Player/#Security/FlashPlayerTrust (for example, /Users/JohnD/Library/Preferences/Macromedia/ Flash Player/#Security/FlashPlayerTrust) These settings affect only the current user (not other users that log in on the computer). If a user without administrative rights installs an application in their own portion of the system, the User Flash Player Trust directory lets the installer register the application as trusted for that user. Similar capability is provided interactively to the user with the Settings Manager. There is also a Global Flash Player Trust directory, used by the administrative user or installers to register an application for all users of a computer (see “Global Flash Player Trust directory” on page 22). These two sets of trust directories have different security precedence (see “Hierarchy of local file security controls” on page 38). Website controls The system administrator of a domain (website) that hosts resources used by Flash applications can designate what resources can be downloaded from their site using a cross-domain policy file. When a SWF file downloads data from a server, it does so with certain credentials from the user, which may include cookies, passwords, private network access, etc. This is why, by default, a SWF file can only download data from servers in its own domain. If the administrator of a server wishes to permit SWF files from other domains to access data from that server (using any user credentials that the server may have provided), the administrator can create policy files specifying such permissions. This is always safe for data that is freely available on the public Internet, but may be risky for data that requires user authentication. There are multiple ways in which a SWF file can read data from the web directly into ActionScript variables, such as by using the ActionScript URLLoader.load()method or by using the ActionScript socket object. The default for network sandboxes is to restrict read permissions to data sources from the origin domain (exact match) of the SWF file. For a SWF file to retrieve data from a domain other than its own, the sandbox from which it is to be fetched (the provider domain) must include a policy file that permits that action. These are the cross-domain policy files, which allow a website administrator to specify (as consulted by and enforced by Flash Player) that the documents that domain serves be freely available to all domains, or available to specific other domains (such as by specifying an exact URL or domain, or specifying a set of related URLs or subdomains using wildcard notation). For more information on policy file formatting, see the following: • The Flash Player TechNote: http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_14213 • The “Flash Player Security” chapter in Programming ActionScript 3.0 (www.adobe.com/go/programmingAS3) Adobe Flash Player 9 Security 29 The cross-domain policy file mechanism is a simple XML file that does the following: • Modifies the read permission for data between sandboxes and across the network. It does not apply to cross-scripting of SWF files. • Applies only to the protocol and port of the server, rather than opening up an entire domain, with one exception: HTTP servers can provide the policy files that govern socket connections. The cross-domain policy file is located, by default, in the root directory of the target server, with the name crossdomain.xml (for example, at www.example.com/crossdomain.xml), or Flash application developers can specify another location by calling the ActionScript loadPolicyFile() method. The scope of the permissions defined in a policy file includes all resources within the directory and within nested subdirectories. Policy files are only able to grant access to a resource; they cannot restrict access. The search order of policy files does not need to be well-defined, because there is no precedence among policy files. If a resource is within the scope of more than one policy file, any one of the policy files may grant access. Note: There are two distinct (basically unrelated) controls that apply to cross-domain actions that might be confused because they have similar names: cross-domain policy files (covered here) are managed by domain administrators to allow network access to data; the ActionScript allowDomain() method is specified by authors to allow client-side cross-domain scripting (discussed in “Developer controls” on page 31). Policy file usage Policy files grant cross-domain permissions for reading data. They permit operations that are not permitted by default. It is important to understand what a policy file enables, rather than simply regarding the default rules as a potential barrier and creating a policy file without considering the consequences. When a domain is specified in a policy file, the site declares that it is willing to allow the operators of any servers in that domain to obtain any document on the server where the policy file resides. Often this is the effect that you want. For example, if a site serves only public documents from a particular server, the site should have no qualms about who can obtain documents on that server, because anyone can simply visit the server and download files that they want. In this situation, it is safe to open the server to all domains (use of a single asterisk "*" as a pure wildcard is supported): Alternatively, if the site serves private documents or anything that requires some form of authentication (such as a password), or if the server is behind a firewall where only certain users can access it, it is risky to put a public policy file on that server. Doing so would enable Flash applications to download documents from the server whenever they run on the computers of users that the server trusts. These applications could potentially reveal private data from the server to people whom the user or website administrator does not trust. If it is necessary to create a policy file in such a situation, it is best that the file permit access for domains that you specifically know need access. For example, if you run a server at example1.com that provides XML data, and you serve Flash applications from www.example2.com, which needs to load the XML data, you could put a policy file on example1.com that enables access specifically from www.example2.com. If you run a server that serves especially sensitive documents, and you know there are no Flash Player files on your server that need to access those documents, it is safest to create a deny-all policy file on that server: Adobe Flash Player 9 Security 30 For a complete description of cross-domain policy files, see the “Flash Player Security” chapter in Programming ActionScript 3.0 (www.adobe.com/go/programmingAS3). Developer controls Developers have many ways that they can designate or control some of the security aspects that apply to a Flash application that they are publishing. Permission mechanisms There are a number of mechanisms available for the author to designate aspects of the desired security environment for the resulting Flash application. Permission mechanisms are APIs that provide for altering the calling application’s security environment. The following table and the sections that follow it describe these APIs: Table 2: Permission mechanism APIs API Names Security.allowDomain() Security.allowInsecureDomain() Description Permit SWF files from a specified sandbox to read (or crossscript) the calling SWF file. The allowInsecureDomain() API also permits access to HTTPS SWF files by non-HTTPS SWF files. Note: For Flash Player 7 and earlier, these methods permitted access to all SWF files in the sandbox of the calling SWF file. Starting with Flash Player 8, these methods permit access only to the calling SWF file itself. Security.loadPolicyFile() Informs Flash Player of the location of a policy file in a nondefault location, or the location of an XMLSocket policy file. Security.exactSettings Determines whether exact or old-style superdomain rules are used to determine the scope of shared objects and privacy settings. Note: For Flash Player 7 and earlier, the value of this property was scoped to an entire sandbox—changing it from one SWF file in a sandbox also changed it for all other SWF files in the same sandbox. In Flash Player 8, the value of this property is scoped to the calling SWF file only. Adobe Flash Player 9 Security 31 API Names LocalConnection. allowDomain() LocalConnection. allowInsecureDomain() Description Specifies one or more domains that can send LocalConnection calls to a LocalConnection instance. In ActionScript 3.0, LocalConnection.allowDomain() functions like Security.allowDomain(): receiving code calls allowDomain(). Like Security.allowDomain(), LocalConnection.allowDomain() supports a single asterisk "*" as a global wildcard. In ActionScript 1.0 and 2.0, these methods are implemented as a user callback. If present, they were called by Flash Player whenever a LocalConnection method call is about to occur. The caller's domain is passed as an argument. The method returns true or false to allow or disallow the call. If unimplemented, calls are only allowed from callers in the same domain. Adobe Flash Player 9 Security 32 Table 3: HTML parameter permission mechanism APIs API Names allowNetworking Description This HTML parameter governs a number of ActionScript APIs. It has the following possible values: "all"—the default. No networking restrictions; player behaves normally. "internal"—SWF files may not call browser navigation or browser interaction APIs, but may call any other networking APIs. "none"—SWF files may not call any networking APIs, nor any SWF-to-SWF communication APIs. allowScriptAccess This HTML parameter governs whether ActionScript can call JavaScript (or other script) in the HTML page (container). It has the following possible values: "never"—Script access is not allowed "sameDomain"— Script access is allowed if the calling SWF file is from the same sandbox as the container. Note: this is the default value for Flash Player 8 and later; "always" was the default value for Flash Player 7 and earlier SWF files. "always"—allowed Table 4: Native method permission mechanism APIs for host applications API Names DisableLocalSecurity EnforceLocalSecurity Description This is a method exposed to host applications to control security settings. It can only be invoked by native code in the host application. Security.allowDomain() Note that calling the Security.allowDomain() method is an all-or-nothing switch; you cannot use the method to open up just a single part of a SWF file to another domain. You should only call the Security.allowDomain() method if you entirely trust the owner of the specified domain not to abuse its rights to read and modify data in your SWF file, and to call ActionScript code in your SWF file. If you have a need to open up just a controlled API to another domain, the LocalConnection.allowDomain() method is a better solution, because you can provide a LocalConnection object that provides only limited functionality to its clients. Adobe Flash Player 9 Security 33 Scripting between SWF files occurs when one SWF file loads another SWF file and then one of the SWF files uses ActionScript to examine or modify variables in the other, or calls functions or methods in the other. Scripting between SWF files requires read permission, so by default it is only permitted with SWF files that are in the same sandbox. Loading of a SWF file, on the other hand, requires only the send permission. So, SWF files are generally allowed to load SWF files from other sandboxes, but security restrictions may prevent those files from communicating with each other. Scripting permissions also affect when an HTML page that uses JavaScript (or another scripting language) may script a Flash application. Flash Player only permits this operation when the HTML page is in the same sandbox as the Flash application it attempts to script, or if appropriate sandbox permissions have been explicitly provided. Applying the rules By default, Flash Player requires that SWF files and non-SWF file script must come from the same domain to be able to script one another. In addition, applications that are served over non-secure protocols, such as HTTP, cannot script those that are served over HTTPS. The same restrictions apply to HTML pages scripting Flash applications. When two applications are from different domains, Flash Player ensures that they have different copies of the ActionScript global object. The global object is usually implicitly referenced. For example, all objects in the Flash Player standard library, such as MovieClip or Array, are part of the global object. Granting scripting between SWF files Applications served from different domains that want to be able to communicate with each other with scripting must be granted cross-domain scripting permission. This is done using the ActionScript method Security.allowDomain(). For example, Flash Player allows an application at http://www.mysite.com/controller.swf that needs to load another application from http://utility.flashutils.com/helper.swf and call methods defined in helper.swf, as long as the following ActionScript is in the helper.swf file: Security.allowDomain("www.mysite.com"); This ActionScript permits any application from the www.mysite.com domain to script helper.swf. Note that, in earlier versions of Flash Player, this ActionScript would have allowed any application from the www.mysite.com domain to script any application from the utility.flashutils.com domain, but since Flash Player 8, the effects of calling the Security.allowDomain() method have been limited to the calling SWF file. A SWF file may also call Security.allowDomain() with the wildcard parameter "*" to allow any domain. This is necessary to allow a local-with-networking SWF file to cross-script a network SWF file. When a SWF file served over the secure HTTPS protocol calls the Security.allowDomain() method, this permits access by other SWF files that are also served over HTTPS, but it does not permit access by other SWF files that are served over insecure protocols, such as HTTP. In order for an HTTP SWF file to cross-script an HTTPS SWF file, the HTTPS SWF file must call the Security.allowInsecureDomain() method. For example, a SWF file at http://www.mysite.com/controller.swf that needs to load a SWF file from https://secure.mysite.com/creditcard.swf and call methods in creditcard.swf is only permitted to do so if the following ActionScript exists in the creditcard.swf file: Security.allowInsecureDomain("www.mysite.com"); Adobe does not recommend this practice, because allowing non-HTTPS documents to access HTTPS documents compromises the security offered by HTTPS. It is best to serve all Flash applications that require scripting access to HTTPS applications over HTTPS. Adobe Flash Player 9 Security 34 The Flash application that uses the Security.allowDomain() method may become vulnerable to crosssandbox hijacking, because this allows full read permissions and cross-scripting to the application by members of the specified sandbox. (Contrast this with the LocalConnection.allowDomain()method, which works differently, as described in “LocalConnection.allowDomain()” on page 36). Security.loadPolicyFile() The policy file allows administrators with write access to a portion of a website to grant an application read access to that portion (see “Policy file usage” on page 30). By default, this file is located in the root directory of the target server. Use of the default location technique is typically best, as it opens the policy file for the entire server; it is compatible with all versions of Flash Player 7 and higher, and it does not require applications to declare anything about policy files. However, if there are reasons why the policy file cannot be placed in a root location on the server, or the policy file needs to be served from a socket server, the alternative would be to use the loadPolicyFile() method. This API was introduced in Flash Player 7 (7.0.19.0) to allow the website to specify a non-default location for the policy file. This mechanism is used by the Flash application to indicate to Flash Player where to look for a policy file that (if it exists and if it indicates permission) would allow that application to read data from that part of that site. If you place a policy file in a directory below the root directory, it only applies to that directory (and directories below it), not the entire server. An author must call this API prior to any operation that may require the policy file; otherwise Flash Player checks the default location on the server for the policy file. Security.exactSettings This is a Boolean value that specifies whether to use superdomain (false) or exact domain (true) matching rules when accessing local settings (such as camera or microphone access permissions) or locally persistent data (shared objects). The default value is true for files published for Flash Player 7 or later, and false for files published with earlier versions of Flash Player. Security.sandboxType This read-only property indicates the type of security sandbox in which the calling SWF file is operating. Security.sandboxType has one of the following values: ƒ remote: This SWF file is from an Internet URL, and will operate under domain-based sandbox rules. ƒ localWithFile: This SWF file is a local file, but it has not been trusted by the user and was not published with a networking designation. This SWF file may read from local data sources but may not communicate with the Internet. ƒ localWithNetwork: This SWF file is a local file and has not been trusted by the user, but it was published with a networking designation. This SWF may communicate with the Internet but may not read from local data sources. ƒ localTrusted: This SWF file is a local file and has been trusted by the user, using either the Settings Manager or a FlashPlayerTrust configuration file. This SWF file may both read from local data sources and communicate with the Internet. Adobe Flash Player 9 Security 35 LocalConnection.allowDomain() The ActionScript LocalConnection class lets you develop SWF files that can send instructions to each other. LocalConnection objects allow communication between two instances of Flash Player, as might occur for a Flash application that includes multiple browser windows. Every LocalConnection object has a LocalConnection.allowDomain() method that accepts a set of domains that may send messages to this instance of the LocalConnection class. An author that calls LocalConnection.allowDomain()agrees to consider messages from other domains that it can examine further and act on or ignore as it chooses. It can therefore effectively select the effects (if any) that other domains can have on it. It can also choose what information to reveal back to the other domains. This supports mutually suspicious applications and allows communication without making either side vulnerable to the other. Security restrictions for LocalConnections A LocalConnection object allows two Flash applications to communicate with each other, even when they are not located in the same instance of Flash Player (for example, when two SWF files are in separate browser windows). LocalConnection objects are available in Flash Player 6 and later. An application calls the LocalConnection.send() method to initiate a remote procedure call over a LocalConnection. When an application calls the LocalConnection.send() method and there is a receiver for the specified channel, Flash Player checks whether the domain of the sender is one of the domains allowed to use the LocalConnection, as specified by the receiver. If so, the call proceeds. An application may also call the LocalConnection.domain property to determine its own domain. By default, Flash Player requires that a LocalConnection sender must come from the same domain as the receiver. In addition, applications that are served over non-secure protocols, such as HTTP, may not make LocalConnection calls to applications that are served over HTTPS. (Conversely, HTTPS applications may make LocalConnection calls to HTTP.) These rules apply only when any of the applications are made for Flash Player 7 or later. If both are made for Flash Player 6, Flash Player uses the old rules. The old rules permit an application to make a LocalConnection call to an application from the same superdomain, and permit HTTP SWF files to make LocalConnection calls to HTTPS sources. When an application made for Flash Player 6 calls the LocalConnection.domain() method, the return value is the application's superdomain. When an application made for Flash Player 7 or later calls the LocalConnection.domain()method (or the LocalConnection.domain property in ActionScript 3.0), the return value is the application’s exact domain. LocalConnection channel names One aspect of LocalConnections continues to use superdomains, even for applications made for Flash Player 7 and later: the domain in a channel name. A channel name is simply the name that a listener connects with and that a sender uses to identify a listener to send to. When a Flash application calls the LocalConnection.connect() method with a channel name that begins with an underscore (_), Flash Player uses the channel name exactly as provided, without regard to domain. However, for channel names that do not begin with an underscore, there is an implicit domain name added to the beginning of the channel name. For example, when a listener from www.mysite.com calls the following: receiving_lc.connect("myChannel"); The channel name becomes mysite.com:myChannel. If a sender from www.mysite.com or store.mysite.com calls the following API: sending_lc.send("myChannel", "methodName"); Adobe Flash Player 9 Security 36 Flash Player sends the call to the channel, mysite.com:myChannel, which corresponds to the listener's connect() call in the example. The only time when an application must add a domain name to a channel name is when it sends to a listener outside its own superdomain. In that case, the sender must explicitly specify the domain and channel name. If a sender from www.anothersite.com were to send to the listener in the previous example, the sender would use the following syntax: sending_lc.send("mysite.com:myChannel", "methodName"); This situation uses the listener's superdomain, not the listener's exact domain. Granting LocalConnection permissions Applications served from different domains that need to be able to make LocalConnection calls to each other must be granted cross-domain LocalConnection permissions. This is done in ActionScript 2.0 by implementing the allowDomain event handler on the LocalConnection listener. In ActionScript 3.0, LocalConnection.allowDomain() is invoked directly by the author, rather than implemented as a callback function. There is a second LocalConnection security method: LocalConnection.allowInsecureDomain(). This functions analogously to the Security.allowInsecureDomain() method: it is required in order for nonHTTPS SWF files to access HTTPS SWF files. Adobe does not recommend using LocalConnection.allowInsecureDomain(), because allowing nonHTTPS documents to access HTTPS documents compromises the security offered by HTTPS. It is best that all Flash SWF files that make LocalConnection calls to HTTPS SWF files are served over HTTPS. Local file system options for authors Flash Player provides a mechanism to simplify workflow for those who frequently work with local SWF files, such developers. If LocalSecurityPrompt=Author is present in a FlashAuthor.cfg file, Flash Player alters its local security behavior as to display the security dialog box when a local SWF file developed for Flash Player 8 or later accesses a resource in another sandbox. This type of access silently fails if the FlashAuthor.cfg file does not exist (as is the case for most users of Flash Player), or if LocalSecurityPrompt=Author is in the FlashAuthor.cfg file. This gives individuals building a Flash application a chance to see and correct all potential failures, rather than experiencing silent failures that could be harder to detect or resolve. Options when publishing When publishing SWF files, authors have two choices for local file security: “access local files only” or “access network only”. These equate to the resultant application, when loaded as local SWF files, being put in the local-with-file-system or the local-with-networking sandboxes, respectively. These settings do not affect SWF files loaded from the network. The default is to place SWF files into the local-with-file-system sandbox. The local content updater is another way to have a SWF file be in the local-with-networking sandbox after compilation. This is valuable for publishers who would like to modify the sandbox as a post-processing step. The local content updater is distributed as both binaries and source, and is available at http://www.adobe.com/support/flashplayer/downloads.html. Adobe Flash Player 9 Security 37 ActiveX control and browser plug-in APIs Applications hosting the Adobe Flash Player ActiveX control or Flash Player plug-in can use the EnforceLocalSecurity and DisableLocalSecurity API calls to control security settings. If DisableLocalSecurity is invoked, the application does not benefit from the local-with-networking and local-with-file-system sandboxes introduced in Flash Player 8. If EnforceLocalSecurity is invoked, the application is able to use all three local sandboxes, as described in the following section, “Hierarchy of local file security controls.” The default behavior for an ActiveX control hosted in a client application is DisableLocalSecurity. The default behavior for the browser plug-in is EnforceLocalSecurity. Hierarchy of local file security controls The preceding sections provide information local file sandboxes, as well as the local file security controls that are provided to administrative users, users, and authors. This section describes how these controls interact to determine which sandbox is used for a specific SWF file. These sandboxes (and the controls related to the sandboxes) have no effect on web-based content. Loading into the local-trusted sandbox Any local SWF file can be placed into the local-trusted sandbox by either the administrative user or the user (websites and developers do not have the authority to place files into the local-trusted sandbox). The Global Flash Player Trust directory allows administrative users to list SWF files that should be placed into the localtrusted sandbox. Users have this ability by default, but the administrative user restricts this ability with the UserTrust control in the mms.cfg file. By default, users are allowed to specify which SWF files should be placed into the local-trusted sandbox with either the User Flash Player Trust directory or by using the Settings Manager. An additional set of controls is provided specifically for backwards compatibility with legacy SWF files. Administrative users or regular users may indicate that SWF files of versions prior to Flash Player 8 that are not explicitly trusted based on the controls listed previously should (or should not) be placed into the localtrusted sandbox. By default, any SWF file prior to Flash Player 8 is placed into the local-with-file-system sandbox. If that legacy SWF file attempts to access the network, Flash displays a dialog box to the user, indicating that the file may require the user to specify that the file should run in the local-trusted sandbox to operate correctly. The administrative user may allow or disallow legacy support via the LocalFileLegacyAction option in the mms.cfg file. In either case, this dialog box does not appear and the administrator’s preference is exercised. If the administrative user does not specify a preference in the mms.cfg file, the Settings Manager provides the user with a mechanism to indicate that all SWF files prior to Flash Player 8 should be placed into the local-trusted sandbox. If neither the administrative user nor the end user exercises these controls, the default behavior applies and the dialog box may appear. Adobe Flash Player 9 Security 38 Loading into the local-with-networking sandbox There is one control that may cause a SWF file to be placed in the local-with-networking sandbox rather than the default local-with-file-system sandbox; developers can mark a SWF file for the local-withnetworking sandbox prior to providing it to the user. This can be done using the authoring tool, or with a post processing of the SWF file. In either workflow, this marker in the SWF file indicates that if Flash Player loads the SWF file from the local file system, the SWF file should be loaded into the local-with-networking sandbox. Adobe provides a post-compiler tool (and source code) to configure a SWF file to use the local-withnetworking sandbox at: http://www.adobe.com/support/flashplayer/downloads.html The default setting: local-with-file-system There is no control that places files into the local-with-file-system sandbox. By default, Flash Player loads local SWF files into the local-with-file-system sandbox. Flash Player integration with native applications Flash Player’s standard local sandboxes may not be appropriate for the security model of all native applications hosting Flash Player, so a control was added to enable the Flash Player client runtime integration with native applications. Application developers integrating the plug-in version of the player should call an API to DisableLocalSecurity or EnforceLocalSecurity. If Flash Player integrators choose EnforceLocalSecurity, local content is placed into one of the three local sandboxes, according to the hierarchy of controls described previously. If Flash Player integrators choose to invoke DisableLocalFileSecurity, all files loaded from the local file system are placed into the local-trusted sandbox. Adobe enables local file security in the stand-alone player and when it integrates Flash Player with any of the major browsers, including Internet Explorer, Mozilla, Netscape, Safari, and Firefox. On the other hand, the authoring player and projectors disable local file security. Flash Player integrators should note that the default behavior for Flash Player varies between the ActiveX control and the browser plug-in. By default, the browser plug-in has local file security enabled, while the ActiveX control has local file security disabled. The default behavior of the browser plug-in changed in Flash Player 8, so it may be possible for an application to function incorrectly after the administrative user upgrades from an earlier version of Flash Player. Therefore, administrative user and user controls provide functionality equivalent to the DisableLocalSecurity API for applications that use the browser plug-in. The Global Flash Player Trust directory allows administrative users to specify whether a particular native application that integrates the browser plug-in should use the local-trusted sandbox for all local content. If the administrative user wants, he or she can provide (or not provide) this control to the user with the UserTrust control in the mms.cfg file. By default, users are allowed to specify the use of the local-trusted sandbox for all local content, and they can use either the User Flash Player Trust directory or the Settings Manager to indicate that an application should use only the local-trusted sandbox. Adobe Flash Player 9 Security 39 Deployment of the Flash Player runtime There are a number of possible runtime deployment methods for installing the Flash Player client runtime on a client computer, making it available to run Flash applications for that client. These deployment options are not new to Flash Player 9. However, with some of the new security characteristics of Flash Player 9 (such as those introduced in ActionScript 3.0), there are some potential security-related runtime effects with the new environment. (These are highlighted throughout this document.) To provide as much upward compatibility as possible, Flash Player recognizes older release applications; however, in some instances, applications by default use a more restrictive security model than they would have previously encountered. Flash Player also provides some mechanisms for authors and users to specify security rules for an application for which you might want different handling. (Previous sections of this document provide more information on the sandbox security model and on security controls.) Regardless of their packaging, delivery method, or target environment, Flash Player plug-ins and ActiveX control components are produced using a common Flash Player base and are digitally signed by Adobe. (For instance, features of Flash Player 9 are common to all Flash Player 9 plug-ins.) Browser plug-ins and ActiveX controls A variety of plug-ins and similar options are available to users for the installation of Flash Player, depending on the combination of the operating system and browser(s) being used on the target client computer. These include Windows plug-ins (such as those for Netscape, Mozilla, and Opera), Macintosh plug-ins (such as those for Safari, Opera, and Netscape), and ActiveX control implementations (such as those for Windows Internet Explorer and AOL). For the complete list of currently supported options, see the following listing of system requirements: http://www.adobe.com/products/flash/flashpro/productinfo/systemreqs/ Some plug-ins are installed by default (initially deployed and configured) with various operating system and browser packages, or completely packaged and installed with selected third-party applications (for example, through various Adobe partnership agreements). Typically, the administrative user is the one who installs (or uninstalls or upgrades) plug-ins. (Sometimes the administrative user is simply the user of the client computer, but inside many security-sensitive organizations such administrative permissions are frequently restricted to specific authorized systems administrators.) Plug-ins run in the same process and address space as the browser itself, and may even share address space with other browsers, which is up to the browser’s implementations. There is also an API (EnforceLocalSecurity) provided for use by third-party applications to enable local file security (see “ActiveX control and browser plug-in APIs” on page 38). However, since some third-party applications can integrate ActiveX controls, developers should exercise special care to ensure that the proper sandbox domain model is used to avoid security issues (real or perceived). Adobe Flash Player 9 Security 40 Authoring player The Flash authoring tools, produced (and signed) by Adobe, include a version of Flash Player specifically for integrated previewing of content. While creating a Flash application, the author can run their content using the authoring player within the authoring environment. This allows the author to test and review the application without (or prior to) deploying it to the target network environment. However, there could be some differences in how the Flash Player security model affects the operation of the application between its execution in the author’s domain and its execution in its eventual deployment environment. More importantly, while the same sandbox security model rules apply in either case (see “Basic sandbox security model” on page 9), the resulting interpretation of those rules in the author’s location might vary significantly from the ultimate deployment configuration. For example, if the author is an internal employee of a corporation (developing the application totally within that corporation’s internal network environment), but creating an application to be deployed to external customers on the Internet, the perspective of the sandbox boundaries seen on the developer’s computer can differ from those experienced by the outside users. If the application draws data from elsewhere within the internal network (considered local for the author residing within that network), that same data source would be outside the local domain when executing the SWF file on the external client’s computer outside the company. For example, internal help systems files might only be available to an external SWF file if they were delivered with the SWF file. Stand-alone player and Flash projector The stand-alone player is distributed with the Flash authoring tools as an EXE file that can load and run SWF files. A Flash projector is an executable file (EXE file on Windows, or an APP file on Mac OS) that incorporates the stand-alone Flash Player. Since a Flash projector file is a SWF file packaged with the specific version of Flash Player, it does not necessarily run in the most current version of the environment available on the platform when it is executed, but rather it runs using the specific packaged version of Flash Player present at the time the Flash projector was produced and published by the author. Therefore, the Flash projector file could encounter differences in access authorizations or other behavior from what another SWF file (such as one loaded as a current SWF file from the web and executed in a more current Flash Player environment) would encounter on the same computer. Additionally, the version of Flash Player embedded within a projector file can be signed by the distributor, but it is not signed by Adobe. From the user’s perspective, there may be real or perceived security differences in the assurance ascribed to who signed the application or in the trust that they place in that source. Similarly, users might be concerned about downloading EXE files to run on their computer. (For more information, see “Executable projector ” on page 44.) Other distributions Flash Player can also be distributed in other forms or with other products or applications, such as Adobe Flash Lite or third-party applications. Documentation specific for those products detail the version of the client runtime used and any other architecture or security issues uniquely related to each of these other products. Adobe Flash Player 9 Security 41 Platform and runtime environment This document focuses on the security protections and access rules that apply for code and data running in Flash Player. All authors and users should be aware that Adobe cannot make security claims for, or significantly modify or enhance, the security capabilities and attributes of the infrastructure in which its products execute. Adobe products also utilize various external security components, such as browser- or OS-provided cryptography, and must rely on the strength of such components as chosen or made available on a given platform. Security flaws might exist in the underlying environment (including the operating system and web browsers) that can potentially be exploited regardless of the applications (including Flash Player) running in that environment. The approach of Adobe is to implement robust security within its own products while “doing no harm” to the rest of the environment (in other words, to introduce no exposures to the rest of the environment, nor allow any avenues for additional exploitation of any existing platform security weaknesses). This provides a consistently high level of security for what Flash applications can do (as managed within Flash Player), regardless of the platform. Because Adobe products are also designed to be backwardscompatible when possible, some environments may be more vulnerable to weaknesses in the browser or operating system, or have weaker cryptography capabilities. Ultimately, users are responsible for their choices of platforms and maintenance of appropriate operational environments, while Adobe products target support for all reasonable combinations. Flash Player adds significant security features over earlier versions of Flash Player, and over what is typically included in other runtime environments. The various default protections and security-related features of Flash Player provide all stakeholders with assurances about the security and privacy of their code and data when processed by Flash Player and its related components. Flash Player also attempts to make the most appropriate security decisions without requiring explicit involvement by the author or user where possible, and minimizes where the author might need to make significant decisions on behalf of all users (as contrasted to other environments, such as Java and .NET). Where any of the Flash Player default access controls may appear overly restrictive for a given type of application or intended data sharing, configuration and administration options exist to allow explicit permissions for broader sharing. Adobe Flash Player 9 Security 42 Deployment of Flash applications Just as there are multiple ways to distribute and install Flash Player, there are multiple methods to distribute individual Flash applications. SWF files Client computers can obtain individual SWF files from a number of sources, such as from external websites or from a local (internal) file system. SWF files are individually assigned to security sandboxes based on their origin when they are loaded into Flash Player. The following sections note the rules, enforced by Flash Player, about what any SWF file within a given sandbox can access. (For more information, see “Basic sandbox security model” on page 9.) Network SWF files Flash Player classifies SWF files downloaded from the network (such as from external websites) in separate sandboxes that correspond to their website origin domains. By default, these files are authorized to access additional resources that come from the specific (exact domain name match) site. (For more information, see “Basic sandbox security model” on page 9.) Network SWF files can be allowed to access additional data from other domains by explicit website and author permissions. (For more information about crossdomain policy files, see “Website controls” on page 29.) Local SWF files Local file describes any file referenced using the “file://” protocol or a UNC path, which does not include an IP address or a qualifying domain. For example, “\\test\test.txt” and “file://test.txt” are considered local files, while “\\test.com\test.txt” and “\\192.150.18.61\test.txt” are not considered local files. Local SWF files from local origins, such as local file systems or UNC network paths, are placed into one of three sandboxes. By default, local SWF files are placed in the local-with-filesupport sandbox. Local SWF files that the author has decided should have network access are placed in the local-with-networking sandbox. Local SWF files that are registered as trusted (by users or by installer programs) are placed in the localtrusted sandbox. Users also have the ability to reassign (move) a local SWF file to or from the local-trusted sandbox based on their security considerations. There are three groups that can make security choices: the author (using developer controls), the administrative user (using administrator controls), and the local user (with user controls). For information about the available options and mechanisms for each of these three areas, see “Permission Controls” on page 19. Communication between the local-with-network and local-with-file-system sandbox is strictly forbidden. Permission to allow such communication cannot be granted by any stakeholder. Local-with-file-system For security purposes, Flash Player 9 places all local SWF files, including all legacy local SWF files, in the local-with-file-system sandbox, by default (unless some other setting is made). For some SWF files built for earlier versions, operations that were allowed prior to Flash Player 9 may be restricted, but this provides the most secure default for the users’ protection. Adobe Flash Player 9 Security 43 From this sandbox, SWF files may read local files (by using the URLLoader.load() method, for example), but they may not communicate with the network in any way. This assures the user that local data cannot be leaked out to the network or otherwise inappropriately shared. Local-with-networking When local SWF files are assigned to the local-with-networking sandbox, they forfeit their local file access. In return, the SWF files are allowed to access the network, with no restrictions on where they may send data. However, a local-with-networking SWF file still is not allowed to read any network-derived data unless permissions are present for that action. Therefore, a local-with-networking SWF file has no local access, yet it has the ability to transmit data over the network and can read network data from those sites that explicitly allow reading to the local-with-networking sandbox through their site-specific access permissions. Local-trusted SWF files assigned to the local-trusted sandbox can interact with any other SWF files, and load data from anywhere (remote or local). Versions of Flash Player prior to Flash Player 8 treated all local SWF files as members of the local-trusted sandbox. This allowed authors to work freely with content under development, and allowed flexibility for SWF file deployments on CD-ROM or other local media. The basis for this rule was the assumption that if a user consented to download or install a SWF file, they were implicitly indicating their trust for that SWF file. This type of local file security is also consistent with other scripting models, such as those used by JavaScript files. With the proliferation of SWF files and their sources, and the variety of ways to distribute them, the Flash platform required additional sandboxes. Therefore, in Flash Player 8 and later, the three separate sandboxes described here allow for the differentiation of access controls for three distinct types of local SWF files. Executable projector files From a security perspective, especially considering the perception and acceptance of security-sensitive users, authors may not want to deploy projector files. A projector file is an executable (EXE or APP) application, which not all users (or their systems security personnel and company security policies) accept from outside sources for downloading and execution on their local computers. In addition, embedded in a projector file is a specific version of Flash Player that may be significantly older than the latest version available when the file is used, thereby forgoing all benefits (including security enhancements) of the newer Flash Player version. The user has no easy way to know (other than possible simple assertions by the distributor) which Flash Player runtime version was used by the application distributor, and therefore what security environment to expect. Those considerations aside, projectors are a common mechanism for deploying content to environments where Flash Player may not be installed or where having absolute control over the version of Flash Player is preferred by an application producer. Adobe Flash Player 9 Security 44 Other security-related information Network protocols Flash Player supports a wide range of common network protocols. The following sections provide brief overviews of the most commonly used protocols and, where particularly relevant, describe some securityrelated effects of different approaches or protocols. AMF Flash Player handles serializing and deserializing ActionScript objects to and from a proprietary terse binary data format called ActionScript Message Format (AMF). AMF serialized objects are the payload of HTTP requests and responses sent between the Flash Player client and the application server. The client-side ActionScript libraries provide the ActionScript objects that a Flash developer uses to connect to and invoke methods on components in the application server. The libraries also provide objects that are helpful for debugging the connection. SMB SMB (Server Message Block) is a message format used by DOS and Windows to share files, directories, and devices. Flash Player can load animations and SWF files from remote SMB shares. Flash has restrictions on what Flash SWF files loaded from SMB shares are allowed to do. RTMP Flash Player uses the Real-Time Messaging Protocol (RTMP) for client-server communication. This is a TCP/IP protocol designed for high-performance transmission of audio, video, and data messages. RTMP sends unencrypted data, including authentication information (such as a name and a password). Although RTMP in and of itself does not offer security features, Flash communications applications can perform secure transactions and secure authentication through an SSL-enabled web server. Flash Player cannot access bitmap data or sound spectrum data for media loaded from RTMP sources, although it can display and play bitmaps and sounds loaded from these servers. Flash Player also provides support for versions of RTMP that are tunneled through HTTP and HTTPS. RTMPT refers to RTMP transmitted within an HTTP wrapper, and RTMPS is RTMP transmitted within an HTTPS wrapper. HTTP HyperText Transfer Protocol (HTTP) defines how messages are formatted and transmitted, and what actions web servers and browsers should take in response to various commands. HTTP is called a stateless protocol, because each command is executed independently, without any knowledge of the commands that came before it. HTTP is an insecure protocol subject to a variety of security weaknesses, so it is not appropriate applications that transmit or provide access to sensitive data. Adobe Flash Player 9 Security 45 HTTPS HTTPS (HTTP over Secure Sockets Layer) is designed to transmit individual messages securely. SSL creates a secure connection between a client and a server, over which any amount of data can be sent securely. SSL works by using a private key to encrypt data that is transferred over the SSL connection. Flash Player uses the operating system or browser to determine whether its data was obtained over a secure HTTPS connection, and records that fact (for instance, using separate sandboxes). Data loaded from HTTPS sites is subsequently treated differently than data from HTTP or other, less-secure, sources. Flash applications can call the ActionScript Security.allowInsecureDomain() method to allow scripting from non-HTTP sites to HTTPS sties, although an author should use this method after reading the considerations listed in the ActionScript 3.0 Language Reference. TCP sockets Transmission Control Protocol (TCP) is used as the underlying protocol for most of the previously described transmission methods. It does not provide any inherent capabilities for securing the data that it transmits. Flash Player can use persistent sockets (through the ActionScript XMLSocket object), which do not use the browser to communicate with the server. Because of this, Flash Player cannot take advantage of the built-in encryption capabilities of the browser. However, it is also possible to use encryption algorithms written in ActionScript to further protect the data that is being communicated. Because the XMLSocket object establishes and maintains an open connection to the server, the XMLSocket object has restrictions for security reasons. By default, the XMLSocket.connect() method can connect only to TCP port numbers greater than or equal to 1024. One consequence of this restriction is that the server daemons that communicate with the XMLSocket object should also be assigned to port numbers greater than or equal to 1024. Port numbers less than 1024 are often used by system services, such as FTP, Telnet, and HTTP, thus the XMLSocket object is by default unable to access these services. The port number restriction limits the possibility that these resources will be inappropriately accessed and abused. By default, the XMLSocket.connect() method can connect only to computers in the same domain where the SWF file resides. The cross-domain policy files that govern XMLSocket connections can be served from HTTP servers or via XML sockets. A policy file can enable cross-domain access or access to ports with numbers less than 1024. Adobe Flash Player 9 Security 46 SSL (Secure Sockets Layer) utilization Basic SSL—browser plug-ins PKI (Public Key Infrastructure) is built into all web browsers that use SSL, and Flash Player uses the browser to do all the work in the interpretation of client-side PKI and in using the browser’s certificate store. An SSL connection is secured by using the PKI certificate of the web server to share a symmetric key with the web browser that is used to encrypt data exchanged between them. When SSL is being used to communicate with a web server, the security functions of the web browser may allow the end user to check the validity of, and view, the associated web server's certificate. This is currently the most common application of SSL. Since it works with no further user interaction, most people are unaware of the other PKI certificate and security features. Some web browsers also allow you to store and use personal PKI certificates for authentication. The key pair and certificate are used with web servers and sites that require authentication through client-side SSL connections. In a client-side SSL connection, the web browser authenticates using a private key to decrypt a message encrypted by the public key. Depending on the features of the browser, the certificate to be used may have to be specified, if there are many certificates available. Some browsers select a certificate that works based on which other certificates were used to sign it. Because Flash Player does not itself implement SSL, all behavior related to certificate verification is determined by the browser. This approach simplifies administration of the client, but it may also result in some variation in behavior between different browsers and operating systems. For example, the symmetric key size and the specific algorithm used for an SSL connection are negotiated by the browser. Similarly, Flash Player does not handle client behavior for certificates that are expired, revoked, self-signed, or do not match the URL of a requested resource. Projector files Because Adobe Flash projector files are executables that run outside a browser, they cannot take advantage of the SSL capabilities of a browser. Because of this, if sensitive information needs to be transferred between the projector file and a server, authors must do one of the following: • Encrypt the data within the application with an ActionScript algorithm, such as an Advanced Encryption Standard (AES) routine. • Require that the application’s users have a secure network connection to the server, such as a virtual private network (VPN) connection. Adobe Flash Player 9 Security 47