Java Deserialization Vulnerability with Service Catalog
Article ID: 7834
Updated On:
Products
Issue/Introduction
Security software tools detected the "“Java Deserialization Vulnerability” on Service Catalog Server
Environment
Service Catalog 12.9, 14.1 and 17.x
All Supported Operating Systems
Cause
The Java Deserialization Vulnerability detected is actually from the third part library commons-collections.jar (from Apache Software Foundation ). The version of this library shipped with catalog 12.9 , 14.1 and 17.0 is 3.2.1.
It is recommended to use 3.2.2 version since version 3.2.2 of commons-collections.jar addressed several security vulnerability issues including "Java Deserialization Vulnerability" in version 3.2.1.
Resolution
1. Download commons-collections-3.2.2-bin.zip from download commons-collections library
2. Unzip to get commons-collections-3.2.2.jar
3. On the Service Catalog server:
1) Create a backup folder on the desktop
2) Stop catalog service
3) Move the original commons-collections.jar file under USM_HOME\view\webapps\usm\WEB-INF\lib\ to the backup folder
4) Rename the downloaded commons-collections-3.2.2.jar as commons-collections.jar and place this commons-collections.jar into USM_HOME\view\webapps\usm\WEB-INF\lib\ to replace the original one
5) Restart Service Catalog service
Additional Information
About Java Deserialization Vulnerability
Article talks about two aspects mainly:
1. Unauthenticated Java Deserialization Vulnerability
In CA Service Catalog, authentication layer is completely outside the context of GWT and it is not possible for any user to send a GWT-RPC call without authentication. In addition, each RPC call is appended with a security handle (&sh parameter) to mitigate potential CSRF attack on that call.
2. Enhanced Classes
The article talks about use of "enhanced classes" to initiate an attack using a third party tool. CA Service Catalog does NOT use the "enhanced classes" feature of GWT.
Feedback
