SSL Poodle Vulnerability in CA Performance Management (CAPM)

Products

• CA Infrastructure Management
• CA Performance Management - Usage and Administration

Issue/Introduction

What is the SSL Poodle Vulnerability?

In late 2014 the SSL Poodle Vulnerability was announced.

This affects all web server applications with SSLv3 enabled. Presence of this vulnerability can allow nefarious users to listen in on SSL traffic allowing access to restricted, private and sometimes in some cases classified information. This only affects web servers capable of SSL configurations, though it is not limited to those servers that have actively configured and utilize SSL functionality for secure access.

This impacts the CA Performance Center (CAPC) server in the CA Infrastructure Management software suite. Being the only host in the suite capable of a supported SSL configuration, it is the only host impacted by this vulnerability. The Data Aggregator (DA), Data Collector (DC) and Data Repository (DR) hosts are not susceptible to this vulnerability.

The current release of the product when this vulnerability was announced is 2.3.4. A fix is included in the r2.5 release and all releases newer than r2.5.

Until such a fix is able to be put in place with an upgrade or a new install, a simple configuration change can be made manually to resolve this and protect the CAPC host from this vulnerability if your release is 2.3.4, 2.4.0 or 2.4.1.

For more information about this topic and this solution review the information found here Configuring_Jetty_for_SSL.

 

Is my CAPC install vulnerable?

We can look to the caperfcenter_console service log files, the CAPC service that controls the web based UI, to validate the status of the SSLv3 protocol being enabled or not. It writes its messages to the PCService.log file found here:

$CAPC_HOME/CA/PerformanceCenter/PC/logs

In a default install located in the /opt directory the path would look like this:

/opt/CA/PerformanceCenter/PC/logs

Looking at PCService.log we can see in messages like this it still supports SSLv3.

INFO  | WrapperSimpleAppMain | 2014-10-17 13:57:23,502 | org.eclipse.jetty.util.ssl.SslContextFactory | Enabled Protocols [SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2] of [SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2]

 

To disable this support and thus prevent this vulnerability complete the following:

 

Modify the jetty-ssl.xml file configurations

There are two to change, one for the SSO service (caperfcenter_sso) and one of the Console service (caperfcenter_console). Both require the same change.

Find the SSO service version in:

$CAPC_HOME/CA/PerformanceCenter/sso/etc/jetty-ssl.xml

Find the Console service version in:

$CAPC_HOME/CA/PerformanceCenter/PC/etc/jetty-ssl.xml

Edit each version of the file by first finding this section:

  <Call name="addConnector">

    <Arg>

      <New class="org.eclipse.jetty.server.ssl.SslSelectChannelConnector">

After that entry is found, after it in the file add these lines of code:

        <Arg>

          <New id="sslContextFactory" class="org.eclipse.jetty.http.ssl.SslContextFactory">

            <Set name="ExcludeProtocols">

              <Array type="java.lang.String">

                <Item>SSLv3</Item>

              </Array>

            </Set>

          </New>

        </Arg>

Save the changes to both files.

 

Restart all CAPC services

The four services involved are named:

caperfcenter_console

caperfcenter_devicemanager

caperfcenter_eventmanager

caperfcenter_sso

Stop them in the order listed above, console first, then devicemanager, then eventmanager then lastly sso. Stop them using the command:

service <serviceName> stop

For example:

service caperfcenter_console stop

Restart them in the reverse order they were stopped. First sso, then eventmanager, then device manager and lastly console.

Restart them using the command:

service <serviceName> start

For example:

service caperfcenter_console start

 

Validate SSLv3 is disabled

If the change was successful and SSLv3 protocol is disabled we can check the PCService.log for a message that looks like this:

INFO  | WrapperSimpleAppMain | 2014-10-17 13:57:23,502 | org.eclipse.jetty.util.ssl.SslContextFactory | Enabled Protocols [SSLv2Hello, TLSv1, TLSv1.1, TLSv1.2] of [SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2]

Note the presence of the SSLv3 protocol has moved from the enabled section when starting this change, to the 'not enabled' section after the change.

At this point while jetty still is capable of supporting SSLv3 it is not enabled.

Perform the same check for SSOService.log looking for the same message.

 

Environment

Release: IMDAGG99000-2.5-Infrastructure Management-Data Aggregator
Component: