CVE-2015-1835: Remote exploit in Apache Cordova

As of June 5th 2015, this blog post acknowledges that IBM is aware of a recently published remote exploitation in Cordova for Android devices.

[Update - July 30th 2015] IBM has responded accordingly to the security vulnerability and has updated this blog post with information on the security patch.

CVE-2015-1835: Remote exploit of secondary configuration variables in Apache Cordova on Android
Severity: High
Vendor: The Apache Software Foundation
Versions Affected: Cordova Android versions up to 4.0.1 (3.7.2 Excluded)

Description: Android applications built with the Cordova framework that don’t have explicit values set in Config.xml can have undefined configuration variables set by Intent. This can cause unwanted dialogs appearing in applications and changes in the application behaviour that can include the app force-closing.

The latest release of Cordova Android entirely removes the ability of configuration parameters to be set by intents. This change is an API change in the platform, and third-party plugins that use values set in the config.xml should make sure that they use the preferences API instead of relying on the Intent bundle, which can be manipulated in this case.

Available iFixes

Worklight/MobileFirst Platform Foundation versions 5.0.5 to 7.0 have been patched and are available to download from IBM Fix Central. Ensure to download at minimum a build from July 7th 2015. For MobileFirst Platform Foundation version 5.0.5, download a build from July 18th 2015 or later.

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 and remember to download the the fix from a build dating July 7, 2015 and onward.

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
After having the newly patched application deployed to the device/emulator,

  1. Kill the application.
  2. In the terminal or command prompt, run the following:
    adb shell am start -n [package_name]/.[MainActivity_name] --es fullscreen true
    and replace [package_name] with your application's package name and [MainActivity_name] with your application's Main Activity name.
  3. Your application should start on your device/emulator and NOT go fullscreen. Since the fullscreen preference was not able to be set through the intent, the patch is successfully applied.

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:
*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:

Also review the latest Cordova security guide:

Inclusive terminology note: The Mobile First Platform team is making changes to support the IBM® initiative to replace racially biased and other discriminatory language in our code and content with more inclusive language. While IBM values the use of inclusive language, terms that are outside of IBM's direct influence are sometimes required for the sake of maintaining user understanding. As other industry leaders join IBM in embracing the use of inclusive language, IBM will continue to update the documentation to reflect those changes.
Last modified on May 01, 2016