Which applications are vulnerable?

Web-based applications built using any release of Flex 4.x compiled using static linkage of the Flex libraries rather than RSL (runtime shared library) linkage are vulnerable. (Versions affected include 4.0, 4.1, 4.5, and 4.5.1.) However, there are certain cases that involve the use of embedded fonts that aren't vulnerable. AIR-based applications aren't vulnerable.

Most applications built with Flex 4.x that were compiled in the default way (specifically, using RSL linkage) aren't vulnerable. However, there are rare cases in which they are vulnerable.

Applications built using any release of Flex before 3.0 are not vulnerable.

Applications built with Flex that are AIR-based (not web-based) are not vulnerable.

SWF files that were created without using Flex (such as files created in Adobe Flash Professional) are not vulnerable.

Check if an application is vulnerable

The steps described under Action I, in the Solution section below, include instructions for checking whether your SWF file is vulnerable.

Solution

There are two actions you can take to protect your users, which are described here. Adobe recommends that you take Action II, which is sufficient even if you do not take Action 1. However, if you find that Action II takes significant time to complete, you can take Action I as a stopgap solution. Then, complete Action II afterwards, when time allows.

Action I: Repair your applications

Repair and redeply vulnerable applications. The most reliable way to repair your applications is to follow Action II, described later. However, a faster, simpler way to repair your application SWF file is to install and run the provided SWF-patching tool, APSB11_25_Patch_Tool.air on your application SWF file. This patch produces a patched but otherwise-identical SWF file. You can then swap in the new file to replace the original SWF file on the deployment website.

However, any subsequent rebuilds of your application from source code are still vulnerable unless you also update your SDK to a fixed version. (This prodecure is described in Action II.) Also, the SWF-patching tool works by searching for a known byte sequence in a particular area of the SWF file. SWF files built or post-processed using compilers, optimizers, or obfuscators other than an official Flex compiler from Adobe can be vulnerable. (They can be vulnerable even if the tool reports no vulnerability.) If you have used a custom compiler or post-processor, skip to Action II rather than using the SWF-patching tool.

The SWF-patching tool is only supported on Windows and Mac OS X. Do not use it on Linux systems. If you do not have a Windows or Mac OS X system available, skip to Action II rather than using the SWF-patching tool.

To use the SWF-patching too, do the following:

Make sure that you have the Adobe AIR runtime installed. If you do not have it, download and install it from http://get.adobe.com/air/.

Read the license agreement near the bottom of this document, in the section titled Flex Application Patch Tool Update License Agreement,. If you agree to its terms, download and install the SWF-patching tool, APSB11_25_Patch_Tool.air. When downloading, some browsers change the filename extension from .air to .zip. Therefore, make sure that you save or rename it with the .air extension.

Make a backup copy of your SWF file to something like "original.swf."

Run the patch tool.

Click Browse and select your SWF file to patch. The SWF file is read, modified, and written to, overwriting the existing SWF file. Be sure that you have backed up the file and have permissions to write to the file. The patch tool writes a log file to the same directory as the selected SWF file. It has the same name as the SWF file, except with .log appended, such as mySWF.swf.log.

Optional: To check whether the SWF file is vulnerable without actually patching it, click Check. Review the resulting output in the large white text area. Depending on the size of your SWF file, the check can take some time.

Click Patch, and wait for patching to complete. Depending on the size of your SWF file, patching can take some time. (It is safe to click Patch even if the SWF file is not vulnerable, so it’s fine to skip the preceding optional check step.)

Review the output, which appears in the large white text area. If the tool successfully patches your SWF, the output looks something like the following:

Indicates that the SWF file is configured in a way by which RSLs it loads determines its vulnerability. Therefore, the SWF-patching tool can't patch it (due to the rare situation of being a Flex 4 SWF file using RSLs but containing no locales). Rebuild your application from source after updating to a fixed SDK version, as described in Action II below.

The tool continues to report this same message even after updating to a fixed SDK version. However, your SWF file cannot be attacked as long as it is dependent on RSLs from a fixed SDK version.

"Failed: Error writing SWF"

Indicates that the SWF file is vulnerable, but could not be patched due to an error writing the changes back to the SWF file on disk. Double-check that you have permissions to write the file.

"Vulnerability not found in ABC block for frame 2, SWF may have already been patched"

Usually indicates that the SWF file has already been patched.

"Vulnerability not found in ABC block for frame 2"

Indicates that the SWF file appears to be a Flex SWF file but does not contain the vulnerable code.

If you are familiar with and set up to run Flex command-line tools, you can optionally take the following steps. (For information about setting up and using Flex command-line tools, see opensource.adobe.com/wiki/display/flexsdk/Setup.) By following these steps, you can examine the changes that were made to your SWF file.

Open a Flex command shell. Assuming that you named your backup copy of the application "original.swf", run the command "SWFDump -abc original.swf > originalSWFDump.txt". The SWFDump command is located in the sdk/bin directory.

Use a text comparison tool to compare originalSWFDump.txt and mySWFDump.txt to verify that the only bytes modified are in the ModuleInfo::load() method. About 80 to 90 lines of output, and the following precede the changes:

Action II: Upgrade to Patched SDKs and Rebuild

Adobe recommends that all previously downloaded or installed copies of the Flex SDK that contain the vulnerability are replaced with the patched versions of the SDK.

To minimize the impact to your Flex projects, Adobe has released numerous different fixed versions of the Flex SDK. You can replace each of your vulnerable versions of the SDK with a fixed version that is nearly identical, aside from the fix itself.

To determine which SDK you have, look in the root folder of the SDK. (This folder is commonly inside the “sdks” folder within the Adobe Flash Builder or Adobe Flex Builder folder). View the flex-sdk-description.xml file in a text editor, and look at the “name” tag. Then, see the table below to determine which fixed version of the Flex SDK to use to replace each of your vulnerable versions.

Alternatively, you can upgrade from a lower-numbered version of the SDK to any higher-numbered version of the SDK in the right column above. Or, you can update to the just-released Flex SDK 4.6 (which does not contain the vulnerability). However, in some cases you can encounter additional project migration issues when moving to a higher-versioned SDK.

Furthermore, installing the just-released Flash Builder 4.6 installs Flex SDKs that do not contain the vulnerability (specifically, Flex SDK 3.6A and Flex SDK 4.6). If you have any other SDK versions that were installed separately from Flash Builder 4.6, remove those versions or replace them with fixed versions.

Important: If you changed any files in an existing copy of the SDK, back up your modified files. Then, reapply the changes in the new SDK after replacing the old SDK with the new one. Remember to consider any configuration files you could have changed, such as frameworks\flex-config.xml.

Important: It's necessary for users of Adobe Flash Builder (or Adobe Flex Builder) to take some additional precautions. Before replacing your SDKs, first make sure to back up all your Flash Builder project folders. In addition, note any Flash Builder project customizations, such as changes to how libraries are linked (default or runtime shared library or “merged into code”), or changes to the HTML template. Then, you can verify that they remain applied or reapply them after switching to the fixed SDKs. (It is safest to examine and make note of such customizations before replacing your SDKs, rather than after.) Once you have downloaded the fixed SDK on your local machine, unregister ("uninstall") the vulnerable SDK and register (“install”) your new SDKs in Flash Builder. Exact steps can vary slightly depending on your version of Flash Builder (or Flex Builder). However, in newest versions, you select Preferences in the Window menu (Windows) or under the Flash Builder menu (Mac OS). Then, expand the “Flash Builder” node on the left side of the dialog, and select the “Installed Flex SDKs” node beneath it. Use the Remove and Add buttons to change your registered SDKs. Then, check the checkbox for whichever new SDK you want to use as the default SDK, and click OK. All projects use the new default SDK, assuming you have removed all the old SDKs. To update which SDK an individual project uses (rather than the default), select the root node of the project in the Package Explorer. Then, select Properties in the File menu, select the “Flex (...) Compiler” node on the left side of the dialog. Finally, select Use a specific SDK, select the desired SDK from the pop-up menu, and click OK. Now reapply any necessary project customizations that you noted earlier.

Important: If you have a 3.x SDK with data visualization components (for example, Charts, AdvancedDataGrid, OLAPDataGrid) or automated testing support, copy those files manually from the existing SDK to the corresponding fixed SDK. These files are not part of the standard 3.x SDKs available on the Flex opensource site. Typically, the Flex Builder 3.x or Flash Builder 4.x installer adds these files to your 3.x SDK or the files could have been added manually. Before copying these files, make sure that the destination SDK has the same version number as the original SDK (but with the “A” suffix).If they are the same, then copy the following files, if present, from your existing 3.x SDK to the corresponding fixed SDK:

Data Visualization files:

frameworks\dmv_automation_build.xml

frameworks\libs\datavisualization.swc

frameworks\locale\<locale>\datavisualization_rb.swc

frameworks\projects\datavisualization\*

frameworks\rsls\datavisualization_3.x.x.x.swf

frameworks\rsls\datavisualization_3.x.x.x.swz

lib\DMV-source.jar

optional files:

samples\explorer\charts_explorer.xml

samples\explorer\charts\*

samples\explorer\controls\AdvancedDataGridExample.mxml

samples\explorer\controls\OLAPDataGridExample.mxml

samples\explorer\printing\AdvancedPrintDataGridExample.mxml

samples_ja\explorer\charts_explorer.xml

samples_ja\explorer\charts\*

samples_ja\explorer\controls\AdvancedDataGridExample.mxml

samples_ja\explorer\controls\OLAPDataGridExample.mxml

samples_ja\explorer\printing\AdvancedPrintDataGridExample.mxml

Automation files:

frameworks\automation_build.xml

frameworks\libs\automation.swc

frameworks\libs\automation_agent.swc

frameworks\libs\automation_dmv.swc

frameworks\libs\automation_flashflexkit.swc

frameworks\libs\qtp.swc

frameworks\locale\<locale>\automation_agent_rb.swc

frameworks\locale\<locale>\automation_rb.swc

frameworks\projects\automation\*

frameworks\projects\automation_dmv\*

frameworks\projects\automation_flashflexkit\*

templates\automation-runtimeloading-files\*

Once you’ve replaced your vulnerable copies of the Flex SDK with fixed versions, rebuild all your applications with Flex. (To be safe, rebuild Flex libraries as well). Your vulnerable SWF files are then replaced with new, nonvulnerable ones. Finally, if you haven’t already redeployed patched versions of your SWF files as part of Action I above, then redeploy your application. Also redeploy and any accompanying SWF files or SWZ library files.

Can the security fix break my application?

Most applications don't have any adverse effects from the fix. If your application uses ModuleLoader to load modules from different domains, or uses the ModuleManager to load modules from different domains and doesn't specify a SecurityDomain in the IModuleInfo.load() method, those modules no longer load.

To fix this problem, use a fixed SDK and specify the trustContent parameter on the ModuleLoader. Or, specify the SecurityDomain.currentDomain in the call to IModuleInfo.load().

Flex Application Patch Tool License Agreement

By downloading, installing or using the APSB11_25_Patch_Tool.air for Flex SDK (the “Software”) provided to you by or on behalf of Adobe Systems Incorporated or its subsidiaries (“Adobe”); you agree to the following terms and conditions. If you do not agree with such terms and conditions; do not use the Software. The terms of an end user license agreement accompanying a particular Software file upon installation or download of the Software shall supersede the terms presented below.

This Software is designed exclusively for use with Flex SDK. Adobe grants you a non-exclusive license to use such Software with the Flex SDK only, provided you possess a valid license from Adobe for Flex SDK. Except as set forth below, such Software is licensed to you subject to the terms and conditions of the End User License Agreement from Adobe governing your use of the Flex SDK, which can be found at http://www.adobe.com/products/eulas/.

You acknowledge that the Software is subject to the U.S. Export Administration Regulations (the “EAR”) and that you will comply with the EAR. You will not export or re-export the Software directly or indirectly, to: (1) any countries that are subject to U.S. export restrictions (including, but not limited to, Cuba, Iran, North Korea, Sudan, and Syria); (2) any end user who you know or have reason to know will utilize them in the design, development or production of nuclear, chemical or biological weapons, or rocket systems, space launch vehicles, and sounding rockets, or unmanned air vehicle systems; or (3) any end user who has been prohibited from participating in the U.S. export transactions by any federal agency of the US government. In addition, You are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Software. If Adobe has knowledge that a violation has occurred, Adobe may terminate your license.

DISCLAIMER OF WARRANTIES: YOU AGREE THAT ADOBE HAS MADE NO EXPRESS WARRANTIES TO YOU REGARDING THE SOFTWARE AND THAT THE SOFTWARE IS BEING PROVIDED TO YOU “AS IS” WITHOUT WARRANTY OF ANY KIND. ADOBE DISCLAIMS ALL WARRANTIES WITH REGARD TO THE SOFTWARE; EXPRESS OR IMPLIED; INCLUDING; WITHOUT LIMITATION; ANY IMPLIED WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE; MERCHANTABILITY; MERCHANTABLE QUALITY OR NONINFRINGEMENT OF THIRD PARTY RIGHTS. Some states or jurisdictions do not allow the exclusion of implied warranties; so the above limitations may not apply to you.

LIMIT OF LIABILITY: IN NO EVENT WILL ADOBE BE LIABLE TO YOU FOR ANY LOSS OF USE; INTERRUPTION OF BUSINESS; OR ANY DIRECT; INDIRECT; SPECIAL; INCIDENTAL; OR CONSEQUENTIAL DAMAGES OF ANY KIND (INCLUDING LOST PROFITS) REGARDLESS OF THE FORM OF ACTION WHETHER IN CONTRACT; TORT (INCLUDING NEGLIGENCE); STRICT PRODUCT LIABILITY OR OTHERWISE; EVEN IF ADOBE HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Some states or jurisdictions do not allow the exclusion or limitation of incidental or consequential damages; so the above limitation or exclusion may not apply to you.

FlexApplicationPatchToolEULA-en_US-09012011_0305

Twitter™ and Facebook posts are not covered under the terms of Creative Commons.