CVE-2015-5204 HTTP header injection vulnerability in Apache Cordova Android File-Transfer Plugin

As of October 6, 2015, this blog post acknowledges that IBM is aware of the recent vulnerability in the Apache Cordova Android File-Transfer Plugin and has responded accordingly.

[Update – October 11th 2015] All patches for MobileFirst Platform Foundation versions 5.0.5 to 7.1.0 are now available on IBM Fix Central. Please download the iFix and follow the instructions below on how to apply the patch.

https://cordova.apache.org/news/2015/09/21/file-transfer-release.html

Available iFixes

MobileFirst Platform Foundation versions 5.0.5 to 7.1.0 have been patched and will be available to download soon from IBM Fix Central.

How to apply the patch and push to users

All customers who build hybrid applications for Android should immediately install the iFix and take the following steps to ensure your application and users are secure:

1. Install the iFix
2. Rebuild your application and redeploy
3. Verify that the patch was applied
4. Use MobileFirst Platform Foundation Server tools to ensure users upgrade. This is not the same as an "in app update" but in fact an upgrade of the actual Android apk installed on the device.

Remember that the iFixes are available from Fix Central.

All customers will need to download the appropriate MobileFirst Platform Foundation iFix and rebuild their applications because these fixes affect native Cordova code that runs on the device. This will ensure that the internal Cordova Android code inside your applications gets refreshed with the security fixes. MobileFirst Platform Foundation Server and other products are not affected because Cordova runs only on the client device.

Note: Your version of Cordova will not be upgraded to a new version when installing the fixpack. Instead you will be using a patched version of the Cordova at the same level as before. For example, if you were using MobileFirst Platform Foundation version 6.2, you will now be using a patched version of Cordova 3.4, not a new upgraded point version of Cordova.

Note: On MobileFirst Platform Foundation versions 6.1 and later, after installing the iFix you will need to remove the Android environment and then add it back to your application. This will put the new cordova.jar file into your project from MobileFirst Platform Foundation Studio. If you have made any manual Android environment customizations, save them before removing the Android environment so that you can restore them after adding the Android environment back to your application.

Rebuilding with the iFix installed will ensure that your application's internal Cordova code is patched. After this, redeploy the application to a device/emulator.

To verify, use the File-Transfer Plugin to upload a file. Add upload options, with the filename of headers set to non-ASCII text such as using 'n' or lots of space characters. If there are no problems uploading, then the vulnerability is avoided and the non-ASCII text characters have been removed.

Below is an example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
var success = function (r) {
    alert("Success:" + r.response);
}

var fail = function (error) {
    alert("Fail");
}

var options = new FileUploadOptions();
options.headers = {'X-Filename':'myFile.txtnCookie:evil  cookie'};
var ft = new FileTransfer();

// !! Assumes variable fileURL contains a valid URL to a text file on the device
ft.upload(fileURL, encodeURI("http://some.server.com/upload.php"), success, fail, options);

If verifying was successful, go ahead and push the newly patched application to users as an update.

It is critical that your users actually download and install the updated application. Until they do this, users will be vulnerable to attack because of the outdated Cordova code. You can use the MobileFirst Platform Foundation Server to remotely disable your application and force users to download the update if they want to continue using your service. The following instructions are for MobileFirst Platform Foundation 7.0 and are from the Knowledge Center located at: http://www-01.ibm.com/support/knowledgecenter/SSHS8R_7.0.0/com.ibm.worklight.deploy.doc/devref/c_updating_wl_apps_in_production.html?lang=en

* Please refer to the appropriate documentation for which ever version of MobileFirst Platform Foundation you are using.

Deploying a new app version and blocking the old version

1. Optional - send notification message to users of the old version, announcing a mandatory update in a few days.
2. In MobileFirst Platform Foundation Studio, increment the app version number.
3. Build and test your project and generate new .wlapp and .apk files for it.
4. Deploy the new .wlapp file to MobileFirst Platform Foundation Server.
5. Submit the new .apk file to the Android app stores.
6. Wait for review and approval, and for the apps to become available.
7. Copy links to the new app version.
8. Block the old version of the app in MobileFirst Platform Foundation Console, supplying a message and link to the new version.

See Locking an application and Remotely disabling application connectivity

* Please refer to the appropriate documentation for which ever version of MobileFirst Platform Foundation you are using).

Other Resources

Please take some time to review the security sections on IBM Developer Works: http://www.ibm.com/developerworks/mobile/worklight/getting-started.html#GS_security

Also review the latest Cordova security guide: https://cordova.apache.org/docs/en/5.1.1/guide_appdev_security_index.md.html