8 April 2008
Adobe released a security update for Flash Player 9 (Flash Player 9,0,124,0) on April 8, 2008, to strengthen the security of Adobe Flash Player for our customers and end users, and to provide further mitigations for previously disclosed vulnerabilities. The Flash Player security update provides further mitigations for issues listed in the December 2007 Security Bulletin APSB07-20 for DNS rebinding and cross-domain policy file vulnerabilities, and Security Advisory APSA07-06 for cross-site scripting vulnerabilities in SWFs.
Customers are advised to review the following Flash Player updates to determine if their content will be impacted, and to begin implementing necessary changes immediately to help ensure a seamless transition. This document provides an overview of the upcoming Flash Player changes, links to TechNotes, and relevant documentation to help you better prepare.
If any of the following situations apply, you should read this article in detail:
Adobe also recommends that customers subscribe to the Security Notification Service to receive e-mail notification for the final security bulletin and advisory releases.
This security update will make the optional socket policy file changes introduced in Flash Player 9,0,115,0 mandatory. A socket policy file is a policy file deployed by a socket. The default socket meta-policy is "all", so socket policy files can be loaded from the socket master policy port (843) or from a custom port.
Note that with this change in Flash Player, HTTP policy files will no longer permit socket access. Flash Player has two types of policy files: HTTP policy files that are crossdomain.xml files on a server and define whether SWFs from other domains can load that server's content; and socket policy files, which define what ports Flash Player can connect to via socket or XMLSocket connections. In the latest Flash Player, the rules regarding socket policy files have changed.
These changes support the goal of DNS hardening, which helps to ensure that ActionScript cannot be used as a means for a DNS rebinding attack (as referenced in Security Bulletin APSB07-20) that could result in an unauthorized socket connection. In the previous update (Flash Player 9,0,115,0), implementing socket policy files was optional; violations of the strict policy file rules result only in warnings in Debug versions of Flash Player. In this update of Flash Player, these warnings are now errors and SWF files that depend on the older socket policy rules may stop functioning as intended.
Flash Player 9,0,115,0 introduced the following concepts:
Any content using sockets or XMLSockets, including configurations in which the following is true:
loadPolicyFilecall to retrieve a socket policy file
Impacted customers should first review the socket policy files section of the Flash Player Developer Center article, Policy file changes in Flash Player 9, in order to learn the new rules and changes. For details on how to determine if your site is affected by this change, see the following TechNote (kb403364): Sockets no longer functional in Flash Player versions greater than 9,0,115,0.
To update your content, you need to create a socket policy file to permit connections to the host socket. The policy file can be served from either the socket master policy port 843 or from the destination port of the socket connection. The socket policy file will need to include all domains that are allowed to connect to the socket, including itself. If the socket policy file is hosted from the master policy file location, be sure to include meta-policies where socket policy files are allowed to be located. You may need to check that your content performs a
loadPolicyFile call to ensure that Flash Player is aware of where to load the policy file from. Use the instructions for configuring policy file logging in Tech Note kb403364 to verify your changes.
At this time, Flash Player allows SWFs to set arbitrary HTTP request headers on GET and POST requests, with the exception of the blacklist of prohibited headers. The April 2008 Flash Player update adds a new security feature to perform a cross-domain policy file check before allowing SWFs to send headers to another domain. This change helps improve web site security by helping to defend against malicious HTTP headers sent by content from other domains. The feature will also help to mitigate a potential UPnP issue (VU#347812) in which routers fail to correctly handle unexpected header values.
In order for a SWF to send a header anywhere other than its own host, the origin domain of the SWF must have explicit permission from the host to which the header is being sent, in the form of a policy file. The existing policy file model will apply, with the same file locations and ActionScript APIs, but a new syntax will be required. To specify header-sending rights, use this new tag:
Flash Player will continue to allow any header not on the blacklist to be sent to the host of the SWF, and additional headers will be added to the blacklist as needed. As a result of this new security feature, the HTTP Authorization header, which was added to the blacklist in Flash Player 9,0,115,0, will be removed from the blacklist but will follow the new cross-domain policy file rules.
The following are impacted:
LoadVars.addRequestHeadermethods, or the ActionScript 3.0
Impacted customers should arrange for a policy file to be added or updated to include the new header policy tags on the site to which the headers are being sent. Additionally, if the crossdomain.xml policy file is in a non-default location—a directory other than the server's document root—customers may need to add an ActionScript call to
loadPolicyFile and republish the affected SWFs.
As a reminder, Adobe strongly encourages customers to implement meta-policy tags within crossdomain.xml in preparation for future changes to cross-domain policy file behavior. The meta-policy file is optional in Flash Player 9,0,115,0 and will throw a security warning but is expected to become mandatory and throw a security error in a future release.
For more details on the new cross-domain policy file tag and syntax, and affected APIs, see the following TechNote (kb403185): Arbitrary headers fail to be sent from the Flash Player to a remote domain.
allowScriptAccess default, which is used when the parameter is not specified, will be updated from "always" to "sameDomain" for all SWFs version 7 and earlier. This changes the behavior of older SWFs to match the current security model and provide greater security by default. The allowScriptAccess permission mechanism is an HTML property of the
The change in default behavior may impact content that uses
allowScriptAccessparameter in the
Other cases that may be impacted include:
If this change impacts your content, you can explicitly specify
allowScriptAccess="always" in the HTML page where the problem occurs. For websites that host a SWF without surrounding HTML, you will need to add the appropriate surrounding HTML to set Flash Player to run in a less privileged mode.
allowScriptAccess="always" exposes your HTML page to abuse.
navigateToURL() will continue to accept them.
This change to the networking APIs further helps mitigate cross-site scripting injections that may result from improper input validation, such as the ones described in Adobe Security Advisory APSA07-06.
Review Creating more secure SWF web applications in the Flash Player Developer Center for more tips on how to develop more secure code. Also, learn how the Flash Player 9 security architecture and new APIs help you deliver trusted content to your users in the Flash Player 9 security white paper.