[NEWS] Security Patch Released for RSA BSAFE SSL-J 3.x

From: support@securiteam.com
Date: 09/16/01


From: support@securiteam.com
To: list@securiteam.com
Subject: [NEWS] Security Patch Released for RSA BSAFE SSL-J 3.x
Message-Id: <20010915223529.A8E04138BF@mail.der-keiler.de>
Date: Sun, 16 Sep 2001 00:35:29 +0200 (CEST)

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -

  Security Patch Released for RSA BSAFE SSL-J 3.x
------------------------------------------------------------------------

SUMMARY

The SSL protocol provides for caching of SSL sessions between subsequent
connections by the same user. Due to a bug in the SSL session caching
feature implemented in RSA BSAFE SSL-J versions 3.x, unauthorized clients
may be able to impersonate authorized clients, thus potentially gaining
access to data intended only for authorized users. The vulnerability does
not give the attacker super-user or "root" privileges on the server.

The problem affects server-side SSL in client authentication mode only
when using RSA BSAFE SSL-J versions 3.0, 3.0.1 or 3.1. The problem does
not affect clients. The problem does not affect servers that do not use
client authentication.

RSA Security has provided an easy migration path and downloadable patches
for customers who are at risk. This bulletin describes the immediate steps
you should take to ensure that your applications remain protected from
malicious attackers.

DETAILS

Vulnerable systems:
Versions 3.0, 3.0.1, or 3.1 of RSA BSAFE SSL-J

Immune systems:
RSA BSAFE SSL-J 1.x and 2.x.
RSA BSAFE SSL-J 3.1.1 or 4.0 beta 2 or higher.
Client applications built with RSA BSAFE SSL-J, irrespective of the RSA
BSAFE SSL-J version number, including all versions of RSA BSAFE SSL-J 3.x.

Server applications built with SSL-J not utilizing client authentication,
irrespective of the RSA BSAFE SSL-J version number, including all versions
of RSA BSAFE SSL-J 3.x.

What is SSL session caching?
The SSL protocol contains provisions to perform fast reconnections once an
initial connection has been performed. The SSL protocol does this be
creating an SSL session, identified by a session ID. This permits client
applications to reconnect to the server by specifying the same session ID
used in earlier transactions. When a client presents a valid session ID, a
much shorter SSL connection setup is performed. This results in faster
connection times and a reduction in processing overhead for server
applications.

How does RSA BSAFE SSL-J handle SSL sessions?
As part of its implementation of the server-side of the SSL protocol, RSA
BSAFE SSL-J maintains a cache of sessions established previously with
client applications. The sessions eventually time out and are removed from
the cache. A client attempting to reconnect after its session has timed
out must renegotiate a full SSL handshake. This behavior is expected under
the SSL specifications.

What is client authentication mode?
When the SSL protocol is in client authentication mode, the client must
present a valid certificate during the connection setup to prove its
identity to the server. This authentication is skipped if the client
presents a valid session ID (see above), since the client must have
already been authenticated during the first connection that initiated the
session.

The caching problem
This problem occurs only in RSA BSAFE SSL-J 3.x when using server-side SSL
in client authentication mode.

If an error occurs while the handshake is being performed, the session's
ID might, under certain conditions, be stored in the cache rather than
being discarded. If the same client then attempts a second connection, the
session ID will already be in the server cache and the shorter version of
the SSL handshake will be performed. Consequently, the client
authentication phase will be skipped and the connection will proceed as if
the client has been successfully authenticated.

The consequences of the vulnerability
This security vulnerability could allow an attacker to circumvent the SSL
client authentication mechanism on servers using RSA BSAFE SSL-J 3.x. The
attacker might then subsequently gain unauthorized access to data that
otherwise would have been secured by the RSA BSAFE SSL-J for the server
application.

When does the problem occur?
Only versions 3.0, 3.0.1, or 3.1 of RSA BSAFE SSL-J used for
client-authenticated server SSL applications are affected.

When does the problem not occur?
The following users are not affected by the problem:

 * Users of RSA BSAFE SSL-J 1.x and 2.x.
 * Users of RSA BSAFE SSL-J 3.1.1 or 4.0 beta 2 or higher.
 * Client applications built with RSA BSAFE SSL-J, irrespective of the RSA
BSAFE SSL-J version number, including all versions of RSA BSAFE SSL-J 3.x.

 * Server applications built with SSL-J not utilizing client
authentication, irrespective of the RSA BSAFE SSL-J version number,
including all versions of RSA BSAFE SSL-J 3.x.

Solution
Customers with active maintenance agreements and who currently use an
affected version of RSA BSAFE SSL-J are recommended to upgrade to the
latest release version of RSA BSAFE SSL-J. The current release version is
RSABSAFE SSL-J 3.1.1.

Customers not currently on active maintenance contracts and who currently
use an affected version are recommended to do the following:

Customers using RSA BSAFE SSL-J 3.0
Download and install the no-cost RSA BSAFE SSL-J 3.0.1 upgrade.
Download and apply RSA BSAFE SSL-J 3.0.1 Patch 1 to the RSA BSAFE SSL-J
3.0.1 distribution.

Customers using RSA BSAFE SSL-J 3.0.1
Download and apply RSA BSAFE SSL-J 3.0.1 Patch 1 to the RSA BSAFE SSL-J
3.0.1 distribution.

Customers using RSA BSAFE SSL-J 3.1
Either:

1) Download and apply RSA BSAFE SSL-J 3.1 Patch 11 to a clean installation
of RSA BSAFESSL-J 3.1. If the customer has already applied patches to the
RSA BSAFE SSL-J 3.1, please reinstall a RSA BSAFE SSL-J 3.1 from the
distribution medium prior to installing Patch 11.
2) If the customer has a current maintenance contract, the customer can
request a copy of the current RSA BSAFE SSL-J 3.1.1 release through their
account manager. RSA BSAFE SSL-J 3.1.1 does not have this bug.

Download
The above patches can be downloaded from:
<http://www.rsasecurity.com/support/bsafe/index.html>
http://www.rsasecurity.com/support/bsafe/index.html

The patches are encrypted. Decryption passwords will be provided to you by
your RSA Account Manager. Please call RSA Security at 650-295-7600 and ask
for the sales department if you have not yet received the passwords.

RSA Security encourages customers to install the respective patch to
proactively prevent security problems. RSA Security continues to make all
possible efforts to ensure our products meet the highest levels quality
and standards our customers expect.

Getting Support and Services
General Technical Support Information:
<http://www.rsasecurity.com/support> http://www.rsasecurity.com/support
SecurCare Online: <http://www.rsasecurity.com/support/securcare>
http://www.rsasecurity.com/support/securcare
Technical Support Telephone Numbers:
<http://www.rsasecurity.com/support/news/tollfree.html>
http://www.rsasecurity.com/support/news/tollfree.html

ADDITIONAL INFORMATION

RSA Security's customer Cisco Systems detected the bug during internal
testing. RSA is not aware of any security breaches resulting from this
bug.

The information has been provided by RSA Security.

========================================

This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.



Relevant Pages

  • Re: [PHP] Quick question, a little 0T i guess... BASIC_AUTH or forms
    ... client to server is to use SSL." ... This offers little more security than plain text. ...
    (php.general)
  • Re: Remote Desktop Web Connection
    ... SSL will not add anything to the security in this case. ... contains just an ActiveX component that acts as Terminal Services client. ... This client will connect to terminal service in same way as any other TS ...
    (microsoft.public.inetserver.iis.security)
  • Re: UsernameOverTransportSecurity+SSL Confusion, please help
    ... If you are using transport security, the following section is not necessary ... The code for the client application looks fine. ... I just want to use SSL. ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: What are the benefits of WSE 3.0 for transport layer security?
    ... Could you please let me know how do you configure for SSL? ... level security vs. transport layer security. ... If I'm not using message layer security are there any benefits in using WSE? ... I would rather not have any additional prerequisites in my client ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: UsernameOverTransportSecurity+SSL Confusion, please help
    ... From my client app if I ... In order to use SSL, I will have to purchase the ... If you are using transport security, the following section is not necessary ... I have a web service, ...
    (microsoft.public.dotnet.framework.webservices.enhancements)