[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ESA-2013-039: RSA BSAFE® SSL-J Multiple Vulnerabilities
- To: Security Alert <Security_Alert@xxxxxxx>, "bugtraq@xxxxxxxxxxxxxxxxx" <bugtraq@xxxxxxxxxxxxxxxxx>, "dm@xxxxxxxxxxxxxxxxx" <dm@xxxxxxxxxxxxxxxxx>
- Subject: ESA-2013-039: RSA BSAFE® SSL-J Multiple Vulnerabilities
- From: Security Alert <Security_Alert@xxxxxxx>
- Date: Wed, 19 Jun 2013 14:50:14 +0000
-----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:
All versions of RSA BSAFE SSL-J except for 6.0.1 and 5.1.2
Unaffected Products:
RSA BSAFE SSL-J 6.0.1 and 5.1.2 (newly released)
Summary:
RSA BSAFE SSL-J 6.0.1 and 5.1.2 contain updates designed to prevent BEAST
attacks (CVE-2011-3389) and SSL/TLS Plaintext Recovery (aka Lucky Thirteen)
attacks (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:
RSA recommends that customers on RSA BSAFE SSL-J 5.1.x or lower upgrade to RSA
BSAFE SSL-J 5.1.2. RSA recommends that customers on RSA BSAFE SSL-J 6.0
upgrade to RSA BSAFE SSL-J 6.0.1.
To address BEAST, RSA introduce a new feature called first block splitting to
RSA BSAFE SSL-J 6.0.1 and 5.1.2. First block splitting is designed to prevent
the BEAST exploit by introducing unknown data into the encryption scheme prior
to the attackers inserted plain text data. This is done as follows:
?1. The first plain text block to be encrypted is split into two blocks. The
first block contains the first byte of the data, the second block contains the
rest.
?2. A MAC is generated from the one byte of data, the MAC key, and an
increasing counter. This MAC is included in the first block.
?3. The one byte of data, along with the MAC, is encrypted and becomes the IV
for the next block. Because the IV is now essentially random data, it is
impossible for an attacker to predict it and replace it with one of their own.
For RSA BSAFE SSL-J 6.0.1 and 5.1.2, first block splitting is engineered to be
enabled by default for vulnerable cipher suites, making the application secure
by default. If required, the application can disable first block 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.
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.
To address Lucky Thirteen, 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.
Obtaining Downloads:
To request your upgrade of the software, please call your local support
telephone number (contact phone numbers are available at
http://www.rsa.com/node.aspx?id=1356 ) for most expedient service. You may also
request your software upgrade online at http://www.rsa.com/go/form_ins.asp .
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.rsa.com/node.aspx?id=1264
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.rsa.com/node.aspx?id=2575
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)
iEYEARECAAYFAlHBwyMACgkQtjd2rKp+ALwI0gCbBNOxiDjCZzTl293lMa53Yy2r
pcsAn2UpV1x8Zg4031kyOrW5LfV2vner
=W+qW
-----END PGP SIGNATURE-----