ESA-2013-039: RSA BSAFE® SSL-J Multiple Vulnerabilities

[Security Alert <Security_Alert@xxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

ESA-2013-039: RSA BSAFE® SSL-J Multiple Vulnerabilities


EMC Identifier: ESA-2013-039

 

CVE Identifier: CVE-2011-3389, CVE-2013-0169

 

Severity Rating: CVSS v2 Base Score: Refer NVD (http://nvd.nist.gov/) for 
individual scores for each CVE

 

Affected Products:

For the BEAST vulnerability, all versions of RSA BSAFE SSL-J except for 6.1.2 
and 5.1.4 are affected.

For the Lucky Thirteen vulnerability, all versions of RSA BSAFE SSL-J except 
for 6.0.1, 6.1.2, 5.1.2, 5.1.3 and 5.1.4 are affected.

 

Unaffected Products:

RSA BSAFE SSL-J 6.1.2 and 5.1.4 (newly released)

 

Summary: 

RSA BSAFE SSL-J 6.1.2 and 5.1.4 contain updates designed to help prevent the 
BEAST vulnerability (CVE-2011-3389). RSA BSAFE SSL-J 6.0.1 and 5.1.2 contain 
updates designed to help prevent the SSL/TLS Plaintext Recovery (aka Lucky 
Thirteen) vulnerability (CVE-2013-0169).

 

Details: 

BEAST

There is a known vulnerability in SSLv3 and TLS v1.0 to do with how the 
Initialization Vector (IV) is generated. For symmetric key algorithms in CBC 
mode, the IV for the first record is generated using keys and secrets set 
during the SSL or TLS handshake. All subsequent records are encrypted using the 
ciphertext block from the previous record as the IV. With symmetric key 
encryption in CBC mode, plain text encrypted with the same IV and key generates 
the same cipher text, which is why having a variable IV is important.

The BEAST exploit uses this SSLv3 and TLS v1.0 vulnerability by allowing an 
attacker to observe the last ciphertext block, which is the IV, then replace 
this with an IV of their choice, inject some of their own plain text data, and 
when this new IV is used to encrypt the data, the attacker can guess the plain 
text data one byte at a time.

 

Lucky Thirteen

Researchers have discovered a weakness in the handling of CBC cipher suites in 
SSL, TLS and DTLS. The ?Lucky Thirteen? attack exploits timing differences 
arising during MAC processing. Vulnerable implementations do not properly 
consider timing side-channel attacks on a MAC check requirement during the 
processing of malformed CBC padding, which allows remote attackers to conduct 
distinguishing attacks and plaintext-recovery attacks via statistical analysis 
of timing data for crafted packets, aka the "Lucky Thirteen" issue.

 

Details of this attack can be found at: 
http://www.isg.rhul.ac.uk/tls/TLStiming.pdf

 

Recommendation:

 

For the BEAST vulnerability:

The best way to help prevent the BEAST attack is to use TLS v1.1 or higher. The 
vulnerability to do with IV generation was fixed in TLS v1.1 (released in 2006) 
so implementations using only TLS v1.1 or v1.2 are engineered to be secure 
against the BEAST exploit. However, support for these higher level protocols is 
limited to a smaller number of applications, so supporting only TLS v1.1 or 
v1.2 might cause interoperability issues.

A second solution is to limit the negotiated cipher suites to exclude those 
that do not require symmetric key algorithms in CBC mode. However, this 
substantially restricts the number of cipher suites that can be negotiated. 
That is, only cipher suites with NULL encryption or cipher suites with 
streaming encryption algorithms (the RC4 algorithm) could be negotiated, which 
might result in reduced security.

 

First block splitting for SSLv3 or TLS v1.0 communications, as a prevention 
against the BEAST exploit, introduced in SSL-J 6.0.1 and SSL-J 5.1.2 is not 
working.

 

In SSL-J 6.1.2 and 5.1.4, the way to prevent the BEAST exploit is to introduce 
some unknown data into the encryption scheme, prior to the attackers inserted 
plain text data. This is done as follows:

 

1.     The first plaintext write will result in one or more encrypted records 
as usual.

2.     The second and subsequent writes are ?split?. That is, each write will 
generate two or more records such that the first encrypted record contains only 
one byte of plaintext.

3.     A MAC is generated from the one byte of data and the MAC key. This MAC 
is appended to the plaintext for the record to be encrypted prior to being 
encrypted.

 

The splitting of the encrypted records generated by the second and subsequent 
writes ensures that the attacker never sees a cipher text block that 
immediately precedes a cipher text block generated from their chosen plaintext. 
This ensures that it is impossible for an attacker to predict the IV that will 
be used to encrypt their chosen plain text and hence the attack cannot be 
executed.

 

Note the following about first block splitting:

     -   Splitting only occurs:

               o    For negotiated cipher suites that use CBC mode.

               o    For protocols SSLv3 or TLS v1.0.

      -  Only application data packets are spilt. Handshake packets are not 
split,

      -   Blocks of plaintext are split for each subsequent call to write data 
to the SSL connection after the first write is sent.

 

For RSA BSAFE SSL-J 6.1.2 and 5.1.4, record splitting is engineered to be 
enabled by default for vulnerable cipher suites, making the application secure 
by default. If required, the application can disable record splitting by 
setting the system property jsse.enableCBCProtection:

 

?  Using the following Java code:

  System.setProperty("jsse.enableCBCProtection", "false");

 

 OR

 

?  On the Java command line, passing the following argument:

  -Djsse.enableCBCProtection=?false?

 

For more information about setting security properties, see section System and 
Security Properties in the RSA BSAFE SSL-J Developer Guide.

 

  

For the Lucky Thirteen vulnerability:

RSA BSAFE SSL-J 6.0.1 and 5.1.2 contain a patch that is designed to help ensure 
that MAC checking is time invariant in servers. Customers can also protect 
against the Lucky Thirteen attack by disabling CBC mode cipher suites on 
clients and servers. Cipher suites that use RC4 and, if TLS 1.2 is available, 
AES-GCM can be used.

 

 

RSA recommends that customers on RSA BSAFE SSL-J 5.1.x (or lower) and 6.x 
upgrade to RSA BSAFE SSL-J 5.1.4 and 6.1.2 respectively to resolve both the 
BEAST and the Lucky Thirteen vulnerabilities.

 

Obtaining Downloads: 

To request your upgrade of the software, please call your local support 
telephone number (contact phone numbers are available at 
http://www.emc.com/support/rsa/contact/phone-numbers.htm) for most expedient 
service. 

Obtaining Documentation:

To obtain RSA documentation, log on to RSA SecurCare Online at 
https://knowledge.rsasecurity.com and click Products in the top navigation 
menu. Select the specific product whose documentation you want to obtain. 
Scroll to the section for the product version that you want and click the set 
link.

Severity Rating:

For an explanation of Severity Ratings, refer to the Knowledge Base Article, 
?Security Advisories Severity Rating? at 
https://knowledge.rsasecurity.com/scolcms/knowledge.aspx?solution=a46604. RSA 
recommends all customers take into account both the base score and any relevant 
temporal and environmental scores which may impact the potential severity 
associated with particular security vulnerability.

Obtaining More Information:

For more information about RSA products, visit the RSA web site at 
http://www.rsa.com.

Getting Support and Service:

For customers with current maintenance contracts, contact your local RSA 
Customer Support center with any additional questions regarding this RSA 
SecurCare Note. For contact telephone numbers or e-mail addresses, log on to 
RSA SecurCare Online at https://knowledge.rsasecurity.com, click Help & 
Contact, and then click the Contact Us - Phone tab or the Contact Us - Email 
tab.

General Customer Support Information:

http://www.emc.com/support/rsa/index.htm

RSA SecurCare Online:

https://knowledge.rsasecurity.com

EOPS Policy:

RSA has a defined End of Primary Support policy associated with all major 
versions. Please refer to the link below for additional details.
http://www.emc.com/support/rsa/eops/index.htm

SecurCare Online Security Advisories

RSA, The Security Division of EMC, distributes SCOL Security Advisories in 
order to bring to the attention of users of the affected RSA products important 
security information. RSA recommends that all users determine the applicability 
of this information to their individual situations and take appropriate action. 
The information set forth herein is provided "as is" without warranty of any 
kind. RSA disclaim all warranties, either express or implied, including the 
warranties of merchantability, fitness for a particular purpose, title and 
non-infringement. In no event shall RSA or its suppliers be liable for any 
damages whatsoever including direct, indirect, incidental, consequential, loss 
of business profits or special damages, even if RSA or its suppliers have been 
advised of the possibility of such damages. Some states do not allow the 
exclusion or limitation of liability for consequential or incidental damages so 
the foregoing limitation may not apply.

About RSA SecurCare Notes & Security Advisories Subscription

RSA SecurCare Notes & Security Advisories are targeted e-mail messages that RSA 
sends you based on the RSA product family you currently use. If you?d like to 
stop receiving RSA SecurCare Notes & Security Advisories, or if you?d like to 
change which RSA product family Notes & Security Advisories you currently 
receive, log on to RSA SecurCare Online at 
https://knowledge.rsasecurity.com/scolcms/help.aspx?_v=view3. Following the 
instructions on the page, remove the check mark next to the RSA product family 
whose Notes & Security Advisories you no longer want to receive. Click the 
Submit button to save your selection.

Sincerely,

RSA Customer Support
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Cygwin)

iEYEARECAAYFAlM9gG8ACgkQtjd2rKp+ALxfXACfcBq3ox0rrD8Xtn+ReCya0oB9
huMAn36FiacTbJug8gvKyI+9IA9tVQFR
=I/i+
-----END PGP SIGNATURE-----