IBM Support

Security Bulletin: IBM UrbanCode Deploy Agents Don't Verify Server Identity (CVE-2016-0271)

Security Bulletin


Mutual authentication in IBM UrbanCode Deploy ensures that unknown agents cannot connect to the server over JMS. However, if a trusted agent is compromised, it can impersonate the server and send work to other agents. Agents do not verify the identity of the server over either HTTP or JMS, and the server does not guarantee that agents receive only messages that were intended for them.

Vulnerability Details

CVEID: CVE-2016-0271
 IBM UrbanCode Deploy could allow a local privileged user to impersonate other users and obtain root privileges on other agents.
CVSS Base Score: 8.2
CVSS Temporal Score: See for the current score
CVSS Environmental Score*: Undefined
CVSS Vector: (CVSS:3.0/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H)

Affected Products and Versions

IBM UrbanCode Deploy 6.0, 6.0.1,,,,,,,,,,,,,, 6.1,,,,, 6.1.1,,,,,,,,, 6.1.2, 6.1.3,,,,,, and 6.2.1 on all supported platforms.

Even when you are using a non-vulnerable version of IBM UrbanCode Deploy, some agent actions might not verify the identity of the server correctly if you are using a vulnerable plug-in. The plug-in must be updated to the latest version. See the following table for information about plug-in versions. If a plug-in is not listed, it is not vulnerable.

Vulnerable VersionsFixed Versions
Artifactory Source Config4 and earlier5 and later
Cloud Foundry15 and earlier16 and later
Docker Source Config4 and earlier5 and later
File System (Versioned) Source Config4 and earlier5 and later
Git Source Config4 and earlier5 and later
IBM AnthillPro Source Config2 and earlier3 and later
IBM Cognos2 and earlier3 and later
IBM MobileFirst Platform (formerly Worklight)7 and earlier8 and later
IBM Rational Asset Manager Source Config3 and earlier4 and later
IBM Rational ClearCase Source Config4 and earlier5 and later
IBM Rational Team Concert SCM Source Config3 and earlier4 and later
IBM UrbanCode Build Source Config2 and earlier3 and later
IBM UrbanCode Deploy Applications69 and earlier70 and later
IBM UrbanCode Deploy Components66 and earlier67 and later
IBM UrbanCode Deploy Configuration Templates7 and earlier8 and later
IBM UrbanCode Deploy Environments71 and earlier72 and later
IBM UrbanCode Deploy Process
2 and later
IBM UrbanCode Deploy Resources68 and earlier69 and later
IBM UrbanCode Deploy System61 and earlier62 and later
IBM UrbanCode Deploy Versions62 and earlier63 and later
Maven Source Config4 and earlier5 and later
Microsoft TFS (Team Foundation Server) Source Config5 and earlier6 and later
Microsoft TFS SCM (Team Foundation Server) Source Config3 and earlier4 and later
NuGet Source Config1 and earlier2 and later
Perforce Helix Source Config3 and earlier4 and later
Subversion Source Config8 and earlier9 and later
TeamCity Source Config5 and earlier6 and later
Websphere Application Server - Deployment90 and earlier91 and later
WinRS Agent Install5 and earlier6 and later
zOS Utility21 and earlier22 and later


For IBM UrbanCode Deploy 6.2 through 6.2.1, upgrade all servers, agents, and relays to IBM UrbanCode Deploy, and update plug-ins as indicated previously. For IBM UrbanCode Deploy versions to, upgrade the server to IBM UrbanCode Deploy Then, complete the following steps to enable certificate verification on the agents.

Enabling Agent Verification of Server Certificate During HTTPS Communication

Part 1: Creating a Valid Server Certificate

The server is installed with an existing private key and self-signed certificate with the alias server in a keystore in the server_installation_dir/opt/tomcat/conf/tomcat.keystore file. The certificate is presented to agents, relays, and users that connect to the server via HTTPS. Because the certificate that is associated with this key has a generic distinguished name (DN), the key must be replaced so that the agent or relay can properly verify the host name of the server. Complete the following steps.

  1. Stop the IBM UrbanCode Deploy server.
  2. Go to the server_installation_dir/opt/tomcat/conf directory of the server computer.
  3. Generate a private key with the correct host name to use for HTTP communication. The existing key that is used for HTTPS communication is located in the tomcat.keystore file with the alias server. The following example shows a command to create a new key by using the Java keytool utility:
    • keytool -genkeypair -alias serverNewCN -keysize 2048 -sigalg SHA256withRSA -keyalg RSA -keystore tomcat.keystore
  4. In the server.xml file, locate the HTTPS connector. The HTTPS connector has the SSLEnabled="true" property. Add a property to specify which alias in the keystore contains the certificate to use: keyAlias="serverNewCN".
  5. (Optional) You can create a certificate signing request by using this key, and then use an internal or external certificate authority to sign it. If you are using a certificate authority to sign the certificate, import the certificate of the CA (rather than the certificate of the UrbanCode Deploy server) into the keystore of the agent or agent relay in Part 2.
  6. Start the server, and upload the latest version of all vulnerable plug-ins (listed previously) to the server.

Part 2: Configuring Agents and Relays to Validate Server Certificates

By default, agents or relays that are upgraded from a pre- build accept all certificates, including self-signed certificates, and do not verify that the host name on the certificate is valid. After the server is configured to present a certificate with a valid host name, and the agents and relays are configured to accept that certificate, a property can be enabled on the agents to force them to verify the server host name, and accept trusted certificates only. Complete the following steps.

  1. For each agent or relay, import the certificate into the keystore of the JRE that is used to run the agent or relay process. By default, the path to the keystore is $JAVA_HOME/lib/security/cacerts. (If the certificate is signed by a certificate authority that is already trusted by the agents and relays, you can skip this step.)
  2. For each agent or relay, either set the UC_TLS_VERIFY_CERTS=yes environment variable on the agent, or add the verify.server.identity=true property to the agent or relay properties file. For an agent, this property file is agent_installation_directory/conf/agent/ For a relay, this property file is relay_installation_directory/conf/
  3. Restart the agent or relay.

Note: Relays are vulnerable only if they are used to cache version artifacts. If you disabled this feature on relays, then only agents must be configured to validate the certificate of the server.

Workarounds and Mitigations

For versions IBM UrbanCode Deploy earlier than 6.1, upgrading to IBM UrbanCode Deploy enables secure HTTPS communication between the server and the agents, and prevents agents from sending work to other agents via JMS. However, even with these changes, agents can still read instructions that are sent to other agents. Because of this behavior, upgrade to IBM UrbanCode Deploy or IBM UrbanCode Deploy as soon as possible. If it is not possible to upgrade to version or later, complete the following steps to mitigate this issue on earlier versions of the product.

1. Upgrade all servers, agent relays, and agents to IBM UrbanCode Deploy

2. For any plug-ins installed on the server that are listed as vulnerable, download the latest version of the plug-in and upload it to the server.

3. Follow the previous instructions in the Remediation/Fixes section under "Enabling Agent Verification of Server Certificate During HTTPS Communication".

4. Implement an ActiveMQ access control list to ensure that clients can only read from, not write to, the agent queues. Instructions for using simple passwords or LDAP for the access control list are available in the attached text file.

Get Notified about Future Security Bulletins



Change History

8 June 2016: Updated to include fix for 6.1.
27 May 2016: Original copy published

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


According to the Forum of Incident Response and Security Teams (FIRST), the Common Vulnerability Scoring System (CVSS) is an "industry open standard designed to convey vulnerability severity and help to determine urgency and priority of response." IBM PROVIDES THE CVSS SCORES ""AS IS"" WITHOUT WARRANTY OF ANY KIND, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. CUSTOMERS ARE RESPONSIBLE FOR ASSESSING THE IMPACT OF ANY ACTUAL OR POTENTIAL SECURITY VULNERABILITY.

[{"Product":{"code":"SS4GSP","label":"IBM UrbanCode Deploy"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"Security","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF010","label":"HP-UX"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"},{"code":"PF035","label":"z\/OS"}],"Version":"6.0;6.0.1;;;;;;;;;;;;;6.1;;;;;6.1.1;;;;;;;;;6.1.2;6.1.3;;;6.2;;;6.2.1;","Edition":"","Line of Business":{"code":"LOB15","label":"Integration"}},{"Product":{"code":"SS4GSP","label":"IBM UrbanCode Deploy"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":" ","Platform":[{"code":"","label":""}],"Version":"6.0;6.0.1;6.1;6.1.1;6.1.2;6.1.3;6.2.1","Edition":"","Line of Business":{"code":"LOB15","label":"Integration"}}]

Document Information

Modified date:
17 June 2018