CVE-2017-2989 - Mitigation
Adobe has released a security update for Adobe Campaign v6.11 (16.11.8790). This update resolves a critical input validation bypass in Web Applications (Microsite, Survey, and so on). It could be exploited to write arbitrary data in the database (CVE-2017-2989).

Description

This document concerns Adobe Campaign v6.0.x instances.

What follows can also be used for v6.1 builds until 8767 but, in this case, a build upgrade is highly recommended.

Note:

Even on the latest 6.1.1, only version 6.x (HTML 5 & Webkit HTML to PDF) is fixed. Update your web applications to this rendering engine. Otherwise, you can follow the v6.0 mitigation procedure below.

Screen_Shot_2017-03-09_at_5_47_24_PM

First mitigation: protect manually all Storage activities

You can:

  • Replace all Storage activities by your javascript code (define yourself the reconciliation keys).
  • Add a Script activity before all Storage ones to do the cleanup (force reconciliation keys & operation).

Second mitigation: protect manually all Storage activities

You can patch two javascript server files:

  • formbase.js (datakit/xtk/fra/js/server/formbase.js). Functions to patch are: 
    • FormBase.prototype.loadContext
    • FormBase.prototype.pushActivityHistory
    • FormBase.prototype.popActivityHistory
  • webApp.js (/datakit/xtk/fra/js/server/webApp.js). Functions to patch are: 
    • PreFillActivity.prototype.checkIdentifierImpl
    • PreFillActivity.prototype.loadEntityImpl
    • WriterActivity.prototype.write

 

You can find these patches in the Extranet Download Center.

Extra protection: restrict the "webapp" operator rights (avoid deleting something else than recipient)

You can also remove administration rights from the "webapp" operator. Detailed instructions are available in the documentation

  1. Create a "webapp" security group.
  2. Remove the ADMINISTRATION named rights from the "webapp" operator.
  3. Add the "webapp" operator to the "webapp" security group.
  4. Add the "webapp" security group for each recipient (or profile) folder which can be populated by web applications or surveys.

Or import the following package:

<package ignoreWarnings="true">
  <entities schema="xtk:group">
    <group label="Web Application agents" name="webapp" type="1">
      <folder _operation="none" name="xtkGroup"/>
      <operatorGroup>
        <group _operation="none" name="webapp" type="1"/>
        <operator _operation="none" name="webapp" type="0"/>
      </operatorGroup>
    </group>
  </entities>
 
  <entities schema="xtk:operatorGroup">
    <operatorGroup _operation="delete">
      <group _operation="none" name="admin" type="2"/>
      <operator _operation="none" name="webapp" type="0"/>
    </operatorGroup>
  </entities>
 
  <installScript>
    var folders = NLWS.xtkQueryDef.create({queryDef:{
      schema: "xtk:folder",
      operation: "select",
      select: { node: [
        {expr: "@name"}, {expr: "@id"}, {expr: "@model"}
      ]},
      where: { condition: [
        {expr:"@model IN ('nmsRecipient', 'nmsVisitor', 'nmsPurl')"}
      ]}
    }}).ExecuteQuery();
     
    for each( folder in folders.getElements("folder") ) {
      if( folder.$model == "nmsPurl" )
        folderRights = "read";
      else
        folderRights = "read|write";
      NLWS.xtkSession.Write({folder: {
          id: folder.$id,
          xtkschema: "xtk:folder",
          _operation: "update",
          rights: {
             _operation:"insertOrUpdate",
             propagate: "true",
             rights:    folderRights,
             "folder-id": folder.$id,
             operator: {
                name: "webapp",
                type: "1",
                _operation: "none"
             }
           }
         }
      });
    }
  </installScript>
 
</package>

As explained in the documentation, you can also create different "webapp" operator to improve security.

Note:

If you want to allow web applications to delete recipients, you have to replace rights: "read|write" by rights: "read|write|delete" in the above package.