IBM Support

Security Bulletin: IBM Mobile Foundation, IBM Worklight, and IBM Worklight Foundation are affected by the following Apache Cordova vulnerabilities: CVE-2014-3500, CVE-2014-3501 and CVE-2014-3502

Security Bulletin


Summary

Apache Cordova, which is used by these products, is vulnerable to Cross-Application Scripting (XAS) and Data Exfiltration vulnerabilities. A remote attacker might exploit these vulnerabilities to expose sensitive data from the mobile application.

Vulnerability Details

CVEID: CVE-2014-3500

DESCRIPTION: Apache Cordova is vulnerable to cross-application scripting, which is caused by improper validation of user-supplied input. A remote attacker might exploit this vulnerability using Android intent URLs to execute script in a victim's web browser within the security context of the hosting web site after the URL is clicked. An attacker might use this vulnerability to steal the victim's cookie-based authentication credentials.

CVSS Base Score: 4.3
CVSS Temporal Score: See https://exchange.xforce.ibmcloud.com/vulnerabilities/94408 for the current score
CVSS Environmental Score*: Undefined
CVSS Vector: (AV:N/AC:M/Au:N/C:N/I:P/A:N)

CVEID: CVE-2014-3501

DESCRIPTION: Apache Cordova might allow a remote attacker to bypass security restrictions, which is caused by an error that is related to the failure to use a specific allowlist when communicating over non-http channels by the WebView component. An attacker might exploit this vulnerability to bypass the HTTP allowlist and launch further attacks on the system.

CVSS Base Score: 5.0
CVSS Temporal Score: See https://exchange.xforce.ibmcloud.com/vulnerabilities/95107 for the current score
CVSS Environmental Score*: Undefined
CVSS Vector: (AV:N/AC:L/Au:N/C:N/I:P/A:N)

CVEID: CVE-2014-3502

DESCRIPTION: Apache Cordova might allow a remote attacker to obtain sensitive information, which is caused by the manipulation of HTML content within a Cordova application. An attacker might exploit this vulnerability to send data from the application to the network.

CVSS Base Score: 4.3
CVSS Temporal Score: See https://exchange.xforce.ibmcloud.com/vulnerabilities/94443 for the current score
CVSS Environmental Score*: Undefined
CVSS Vector: (AV:N/AC:M/Au:N/C:P/I:N/A:N)

Affected Products and Versions

  • IBM Mobile Foundation and IBM Worklight Consumer Edition Versions 5.0.5.0 and 5.0.5.1
  • IBM Mobile Foundation and IBM Worklight Enterprise Edition Versions 5.0.5.0 and 5.0.5.1

  • IBM Mobile Foundation and IBM Worklight Consumer Edition Versions 5.0.6.0, 5.0.6.1 and 5.0.6.2
  • IBM Mobile Foundation and IBM Worklight Enterprise Edition Versions 5.0.6.0, 5.0.6.1 and 5.0.6.2


  • IBM Mobile Foundation and IBM Worklight Consumer Edition Versions 6.0.0.0, 6.0.0.1 and 6.0.0.2
  • IBM Mobile Foundation and IBM Worklight Enterprise Edition Versions 6.0.0.0, 6.0.0.1 and 6.0.0.2


  • IBM Worklight Consumer Edition Versions 6.1.0.0 and 6.1.0.1
  • IBM Worklight Enterprise Edition Versions 6.1.0.0 and 6.1.0.1


  • IBM Worklight Foundation Consumer Edition Version 6.2.0.0
  • IBM Worklight Foundation Enterprise Edition Version 6.2.0.0

Remediation/Fixes


Download the latest interim fix for your product and version:


V5.0.5: IBM Mobile Foundation and IBM Worklight Consumer Edition, IBM Mobile Foundation and IBM Worklight Enterprise Edition

V5.0.6: IBM Mobile Foundation and IBM Worklight Consumer Edition, IBM Mobile Foundation and IBM Worklight Enterprise Edition

V6.0.x: IBM Mobile Foundation and IBM Worklight Consumer Edition, IBM Mobile Foundation and IBM Worklight Enterprise Edition

V6.1.x: IBM Worklight Consumer Edition, IBM Worklight Enterprise Edition

V6.2.x: IBM Worklight Foundation Consumer Edition, IBM Worklight Foundation Enterprise Edition


After applying the appropriate fix, additional instructions are needed for the CVE-2014-3500, CVE-2014-3501 and CVE-2014-3502 issues. Complete the following steps:

  1. Install the Worklight Studio Fix.
    Because these fixes affect native Cordova code that runs on the device, you need to download the appropriate Worklight Studio interim fix and rebuild your applications. This process ensures that the internal Cordova Android code inside your applications gets refreshed with the security fixes. Because Cordova runs only on the client device, Worklight Server and other products are not affected. See the fixes through the previous list of links.

  2. Modify the Cordova allowlist
    One of the security fixes involves creating a new allowlist for non HTTP and HTTPS protocols. If your application uses other protocols besides http:// and https://, such as sms:, mailto:, geo:, and so on., then you need to make some configuration changes to add these protocols to the allowlist. Complete the following steps to make these configuration changes:
    1. Open the Cordova config.xml file, which is located in yourProject > apps > yourProject > android > native > res > xml > config.xml

    2. Scroll to your allowlist entries. You should see items listed like this code:

      <access origin="https://my.company.com/resources" />
      <access origin="http://*.othersupplier.com" />



    3. For every non HTTP or HTTPS protocol that you use, you need to add a allowlist entry like this code:

      <access origin="sms://*" launch-external="true" />
      <access origin="
      mailto://*" launch-external="true" />



      The launch-external attribute tells Cordova to allow this URL to be handled by other applications in Android system and not by the currently running Cordova or Worklight application. This approach means that when a user clicks a <a href="sms:555..."> link, Android lets whatever application is registered to sms: handle the request.


      The only entry in your allowlist might look like this code:
      <access origin="*" />


      In this instance, your application allows resource requests to any Internet resource, which might open your application to certain kinds of attacks. You should list specific domains in this tag that you want to be able to access.


      Your allowlist might look like this code:

      <access origin="https://www.ibm.com" />
      <access origin="
      https://my-worklight-server.company.com" />


      If it looks like the previously listed code, your application utilizes the mailto: protocol to open an email client for a user, and you use the geo: protocol to display a map, then you should modify the allowlist to look like:

      <access origin="https://www.ibm.com" />
      <access origin="
      https://my-worklight-server.company.com" />
      <access origin="
      mailto://*" launch-external="true" />
      <access origin="geo://*" launch-external="true" />


      If you do not utilize any protocol other than file://, data://, and content://, then you can leave your allowlist as is. Because file://, data://, and content:// are essential protocols for Cordova internals, these protocols are allowed, by default, and do not need to be in the allowlist explicitly. All actions that use protocols that are not added to the allowlist are treated as no-ops and ignored by Cordova.

  3. Rebuild your application and redeploy to your users
    After making these changes to the allowlist (if needed), you need to rebuild your Android application. Rebuilding with the interim fix installed ensures that your application's internal Cordova code is patched. Even if you did not need any changes to the allowlist, you still need to install the interim fixe and rebuild your Android application. After this process, you need to redeploy your application to your users as an update.

  4. Use Worklight Server tools to ensure users upgrade
    Even if you follow the previous steps and create a new Android application, it is critical that your users actually download and install the updated application. Until they do download it, users are vulnerable to attack because of the outdated Cordova code. You can use Worklight server to remotely disable your application and force users to download the update if they want to continue using your service. Refer to the appropriate documentation for whichever version of Worklight you are using.


Deploying a new application version and blocking the old version
Complete the following steps:
  1. Optional: Send a notification message to users of the old version that announces a mandatory update in a few days. See Displaying a notification message on application startup and Defining administrator messages from Worklight Console in multiple languages.

  2. In Worklight Studio, increment the application version number.

  3. Build and test your project and generate new .wlapp and .apk files for it.

  4. Deploy the new .wlapp file to Worklight Server.

  5. Submit the new .apk file to the appropriate app store.

  6. Wait for review and approval, and for the applications to become available.

  7. Copy links to the new application version.

  8. Block the old version of the application in the Worklight Console, supply a message, and link to the new version. See Locking an application and Remotely disabling application connectivity.

Workarounds and Mitigations

None

Get Notified about Future Security Bulletins

References

Off

*The CVSS Environment Score is customer environment specific and will ultimately impact the Overall CVSS Score. Customers can evaluate the impact of this vulnerability in their environments by accessing the links in the Reference section of this Security Bulletin.

Disclaimer

Review the IBM security bulletin disclaimer and definitions regarding your responsibilities for assessing potential impact of security vulnerabilities to your environment.

[{"Product":{"code":"SSZH4A","label":"IBM Worklight"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"Studio","Platform":[{"code":"PF003","label":"Android"}],"Version":"6.2;6.1.0.1;6.1;6.0.0.2;6.0.0.1;6.0;5.0.6.2;5.0.6.1;5.0.6;5.0.5.1;5.0.5","Edition":"Consumer;Enterprise","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
17 June 2018

UID

swg21681138