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

CVE-2015-5204: HTTP header injection vulerability in Apache Cordova File Transfer Plugin for Android Severity: Medium Vendor: The Apache Software Foundation Versions Affected: Cordova Android File Transfer Plugin (1.2.1 and below)

Description: Android applications built with the Cordova framework that use the File Transfer Plugin can have the HTTP headers set by that plugin be manipulated by the filename being uploaded. This allows for for cookies to be forged by the Cordova application, or for the file payload to be replaced in some situations. Remotely hosted applications and applications developed with Cordova that allow the user to manually enter the filename are especially vulnerable to this issue.

Upgrade path: Developers who are concerned about this issue should install version 1.3.0 or higher of the Cordova File Transfer Plugin and rebuild their applications. This plugin now conforms with RFC-2616 and no longer allows non-ASCII characters and control characters in header names or values. Any non-ASCII characters will be removed from the header. Developers should be aware, and encode these characters before adding the values to the header.

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.
1. Install the iFix

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.

2. Rebuild your application and redeploy

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.

3. Verify that the patch was applied

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.

4. Use MobileFirst Platform Foundation Server tools to ensure users upgrade

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

Last modified on May 01, 2016
Share this post: