IBM Support

How to block the Install URL from being accessed with CLM

Technote (FAQ)


Question

How do you block the install URL from being accessed with IBM Rational Team Concert (RTC), IBM Rational Quality Manager (RQM) and Rational Requirements Composer (RRC)?

Cause

Due to OSGI Security vulnerability, the install URL allows unauthenticated users to post an update to the jazz application.

Answer

This vulnerability has been corrected in Collaborative Lifecycle Management (CLM) applications version 4.0.6. An upgrade to 4.0.6 is preferred to resolve this issue. As mentioned below, accessing the vulnerable URL on 4.0.6 will result in a blank page, which is expected.

If you are unable to upgrade, you will need to update the web.xml file in each application WAR file for your CLM deployment and Jazz Team Server (including jazz.war, admin.war, ccm.war, qm.war, rm.war, vvc.war, rdm.war and jts.war) to block the install URL from being accessed. Updating the converter.war and clmhelp.war is not required.

NOTE: If you upgrade your server to any version prior to 4.0.6, ensure that the following steps are completed in the new web.xml file, as they are not included in the product until 4.0.6.


If you are using Apache Tomcat Application Server:

  1. Stop the Tomcat Application Server

  2. Backup the web.xml file from the following directory:
    <JAZZ_HOME>\server\tomcat\webapps\<application>\WEB-INF\

  3. Open the web.xml file for editing.

  4. Paste the following as a child of the <web-app> element.
    NOTE: If this is pasted incorrectly, or not as a child of the <web-app> element, you will receive a parse error when the application is started.

    <security-constraint>
    <web-resource-collection>
    <web-resource-name>generally restricted methods</web-resource-name>
    <url-pattern>/install/*</url-pattern>
    </web-resource-collection>
    <auth-constraint/>
    </security-constraint>


  5. Zip up the application folder from <JAZZ_HOME>\server\tomcat\webapps\<application>\ and save as <application>.war.
    This will overwrite the existing WAR file in the webapps directory to ensure that this change is permanent (and not restricted to the current running configuration of the application).
    Example (RTC):
    If you are using the context root /ccm, there will be a ccm directory in the webapps folder. This folder needs to be zipped up and renamed from .zip to .war. This will allow the WAR file (ie. application) to be run within the Tomcat application server. When it is run, it is extracted to the ccm directory which was originally present.

  6. Delete the Apache Tomcat temporary files located in the following directories:
    <OrigInstallDir>/server/tomcat/temp
    <OrigInstallDir>/server/tomcat/work/Catalina/localhost

  7. Restart the Tomcat Application Server


If you are using WebSphere Application Server:

You will need to modify the web.xml file from the application WAR files that were previously installed into IBM WebSphere Application Server. This change needs to be done for each application.

  1. Extract the application WAR files into a temporary area to retrieve the web.xml file.

  2. Navigate to 
    ..WebSphere/AppServer/profiles/<appserver_name>/installedApps/<node_name>/<app_ear>/<app>/WEB-INF/

    Example: ../jts_ear/jts/WEB-INF/

  3. Backup the web.xml file
  4. Open the web.xml file

  5. Paste the following as a child of the <web-app> element.
    NOTE: If this is pasted incorrectly, or not as a child of the <web-app> element, you will receive a parse error when the application is started.

    <security-constraint>
    <web-resource-collection>
    <web-resource-name>generally restricted methods</web-resource-name>
    <url-pattern>/install/*</url-pattern>
    </web-resource-collection>
    <auth-constraint/>
    </security-constraint>

  6. Make sure that WebSphere Application Server is running and navigate to https://localhost:9043/ibm/console/logon.jsp

  7. Click Applications > WebSphere enterprise applications > Enterprise Applications

  8. Select jts_war and click Update

  9. Select Replace or add a single file

  10. In the Specify the path beginning with the installed application archive file to the file to be replaced or added field, enter jts.war/WEB-INF/web.xml

  11. Click Browse and select the same web.xml file that was modified in a previous step

  12. Click Next and follow through until the application has been saved

  13. Repeat the preceding steps for other installed applications (ccm.war, qm.war, rm.war, and admin.war)

  14. Delete the WebSphere cache:
    profile_root/wstemp
    profile_root
    /temp

  15. Go back to the Enterprise Applications panel and stop and start the CLM applications.


Verification Testing
To ensure the above steps were successful, navigate to the following URL for each application.
https://<server>:<port>/<application>/install

You should receive a 403 HTTP error. This will either indicate a "Forbidden" error, or "Access is precluded by configuration." once the fix has been applied.


The steps outlined in this technote work by completely blocking all access to the vulnerable URL.

Prior to applying the fix, navigating to the below URL should result in a blank page.
If you are testing on 4.0.6, this defect has been resolved. Navigating to this page will result in a blank page.

The actual vulnerability is only exploitable through a multipart POST request, and so the 4.0.6 code fix is more granular and works by causing the system to respond with a 403 response only on a multipart POST to the vulnerable URL. If you issue a GET request to a 4.0.6 system you will receive a blank page in response; the HTTP status for the call will be 200 OK. If you issue a multipart POST request to a 4.0.6 system you will see the 403 Forbidden response. If you issue a POST that does not have the Content-Type header set to multipart, you will receive a blank page in response.; the HTTP status for the call will be 200 OK. There are various tools and browser plug-ins available that can issue a POST request if you wish to verify your 4.0.6 system is secured.

If you test a pre-4.0.6 system with a POST request, you will receive a 403 only if you have taken the steps outlined in this technote to block the vulnerable URL. You will receive a 200 response and a blank page if the pre-4.0.6 system is still vulnerable. You do not need to supply any data with the POST request to perform the test.


Leverage the Jazz Community
Jazz and Rational Team Concert have an active community that can provide you with additional resources. Browse and contribute to the User forums, contribute to the Team Blog and review the Team wiki.
Refer to technote 1319600 for details and links.

Related information

A Japanese translation is available


Cross reference information
Segment Product Component Platform Version Edition
Software Development Rational Quality Manager Web App Server 2.0, 2.0.0.1, 2.0.0.2, 2.0.1, 2.0.1.1, 4.0, 4.0.0.1, 4.0.0.2, 4.0.1, 4.0.2, 4.0.3, 4.0.4, 4.0.5
Software Development Rational Requirements Composer Web App Server 2.0, 2.0.0.1, 2.0.0.2, 2.0.0.3, 2.0.0.4, 3.0.1.5, 3.0.1.6, 4.0, 4.0.0.1, 4.0.0.2, 4.0.1, 4.0.2, 4.0.3, 4.0.4, 4.0.5

Document information

More support for: Rational Team Concert
Repository

Software version: 4.0, 4.0.0.1, 4.0.0.2, 4.0.1, 4.0.2, 4.0.3, 4.0.4, 4.0.5

Operating system(s): Linux, Windows

Reference #: 1664698

Modified date: 04 March 2014