Security Bulletin
Summary
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
DESCRIPTION: 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 https://exchange.xforce.ibmcloud.com/vulnerabilities/111051 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.0.1.1, 6.0.1.2, 6.0.1.3, 6.0.1.4, 6.0.1.5, 6.0.1.6, 6.0.1.7, 6.0.1.8, 6.0.1.9, 6.0.1.10, 6.0.1.11, 6.0.1.12, 6.0.1.13, 6.1, 6.1.0.1, 6.1.0.2, 6.1.0.3, 6.1.0.4, 6.1.1, 6.1.1.1, 6.1.1.2, 6.1.1.3, 6.1.1.4, 6.1.1.5, 6.1.1.6, 6.1.1.7, 6.1.1.8, 6.1.2, 6.1.3, 6.1.3.1, 6.1.3.2, 6.2.0.0, 6.2.0.1, 6.2.0.2, 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 Versions | Fixed Versions | |
Artifactory Source Config | 4 and earlier | 5 and later |
Cloud Foundry | 15 and earlier | 16 and later |
Docker Source Config | 4 and earlier | 5 and later |
File System (Versioned) Source Config | 4 and earlier | 5 and later |
Git Source Config | 4 and earlier | 5 and later |
IBM AnthillPro Source Config | 2 and earlier | 3 and later |
IBM Cognos | 2 and earlier | 3 and later |
IBM MobileFirst Platform (formerly Worklight) | 7 and earlier | 8 and later |
IBM Rational Asset Manager Source Config | 3 and earlier | 4 and later |
IBM Rational ClearCase Source Config | 4 and earlier | 5 and later |
IBM Rational Team Concert SCM Source Config | 3 and earlier | 4 and later |
IBM UrbanCode Build Source Config | 2 and earlier | 3 and later |
IBM UrbanCode Deploy Applications | 69 and earlier | 70 and later |
IBM UrbanCode Deploy Components | 66 and earlier | 67 and later |
IBM UrbanCode Deploy Configuration Templates | 7 and earlier | 8 and later |
IBM UrbanCode Deploy Environments | 71 and earlier | 72 and later |
IBM UrbanCode Deploy Process | 1 | 2 and later |
IBM UrbanCode Deploy Resources | 68 and earlier | 69 and later |
IBM UrbanCode Deploy System | 61 and earlier | 62 and later |
IBM UrbanCode Deploy Versions | 62 and earlier | 63 and later |
Maven Source Config | 4 and earlier | 5 and later |
Microsoft TFS (Team Foundation Server) Source Config | 5 and earlier | 6 and later |
Microsoft TFS SCM (Team Foundation Server) Source Config | 3 and earlier | 4 and later |
NuGet Source Config | 1 and earlier | 2 and later |
Perforce Helix Source Config | 3 and earlier | 4 and later |
Subversion Source Config | 8 and earlier | 9 and later |
TeamCity Source Config | 5 and earlier | 6 and later |
Websphere Application Server - Deployment | 90 and earlier | 91 and later |
WinRS Agent Install | 5 and earlier | 6 and later |
zOS Utility | 21 and earlier | 22 and later |
Remediation/Fixes
For IBM UrbanCode Deploy 6.2 through 6.2.1, upgrade all servers, agents, and relays to IBM UrbanCode Deploy 6.2.1.1, and update plug-ins as indicated previously. For IBM UrbanCode Deploy versions 6.1.0.0 to 6.1.3.2, upgrade the server to IBM UrbanCode Deploy 6.1.3.3. 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.
- Stop the IBM UrbanCode Deploy server.
- Go to the server_installation_dir/opt/tomcat/conf directory of the server computer.
- 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
- 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".
- (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.
- 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-6.2.1.1 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.
- 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.)
- 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/installed.properties. For a relay, this property file is relay_installation_directory/conf/agentrelay.properties.
- 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 6.0.1.14 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 6.1.3.3 or IBM UrbanCode Deploy 6.2.1.1 as soon as possible. If it is not possible to upgrade to version 6.1.3.3 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 6.0.1.14.
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.
SimpleAuthACLInstructions.txt
Get Notified about Future Security Bulletins
References
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.
Disclaimer
Review the IBM security bulletin disclaimer and definitions regarding your responsibilities for assessing potential impact of security vulnerabilities to your environment.
Was this topic helpful?
Document Information
Modified date:
17 June 2018
UID
swg2C1000150