Hash: SHA1

             AUSCERT External Security Bulletin Redistribution

          ESA-2012-029: RSA BSAFE® SSL-C Multiple Vulnerabilities
                             12 September 2012


        AusCERT Security Bulletin Summary

Product:          RSA BSAFE SSL-C
Publisher:        EMC
Operating System: Windows
                  Red Hat
Impact/Access:    Access Privileged Data -- Remote with User Interaction
                  Denial of Service      -- Remote/Unauthenticated      
Resolution:       Patch/Upgrade
CVE Names:        CVE-2012-2131 CVE-2012-2110 CVE-2011-3389

Reference:        ESB-2012.0732

- --------------------------BEGIN INCLUDED TEXT--------------------

ESA-2012-029: RSA BSAFE® SSL-C Multiple Vulnerabilities 

EMC Identifier: ESA-2012-029
CVE Identifier:  CVE-2011-3389, CVE-2012-2110, CVE-2012-2131 

Severity Rating: See below for scores for individual issues 

Affected Products:
All versions of RSA BSAFE SSL-C prior to 2.8.6, all platforms

Unaffected Products:


RSA BSAFE SSL-C 2.8.6 contains fixes designed to [prevent] BEAST attacks 
(CVE-2011-3389) and buffer overflow vulnerability 


This release includes fixes for the following vulnerabilities:

1.BEAST (Browser Exploit Against SSL/TLS) attack (CVE-2011-3389
>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.
CVSSv2 Base Score: 4.3 (AV:N/AC:M/Au:N/C:P/I:N/A:N)

2.Buffer overflow vulnerability (CVE-2012-2110/CVE-2012-2131)
SSL-C contains code that does not properly interpret integer data, which could 
allow buffer overflow attacks using crafted DER (Distinguished Encoding Rules) 
data, such as in X.509 certificate or an RSA asymmetric key.
CVSSv2 Base Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)


For BEAST (Browser Exploit Against SSL/TLS) attack:
The best way to help prevent this attack is to use TLS v1.1. The vulnerability 
to do with IV generation was fixed in TLS v1.1 (released in 2006) so 
implementations using only TLS v1.1 are engineered to be secure against the 
BEAST exploit. However, support for this higher level protocol is limited to a 
smaller number of applications, so supporting only TLS v1.1 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.

In RSA BSAFE SSL-C 2.8.6, the BEAST exploit is prevented by introducing some 
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 
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.
To manage this first block splitting in RSA BSAFE SSL-C 2.8.6, either for an 
SSL context or SSL object, call R_SSL_CTX_set_options() or R_SSL_set_options()
respectively, with the SSL_OP_SPLIT_FIRST_FRAGMENT identifier, this option is 
enabled by default.

For more information about these functions and identifiers, see the RSA BSAFE 
SSL-C 2.8.6 API Reference Guide.

For Buffer Overflow vulnerability:
RSA strongly recommends that RSA BSAFE SSL-C customers upgrade to RSA BSAFE 
SSL-C 2.8.6 that contains upgrades designed to resolve this issue. 

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 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 

Obtaining More Information:

For more information about RSA BSAFE, visit the RSA web site at 

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 

General Customer Support Information:


RSA SecurCare Online:


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. 

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.

EMC Product Security Response Center



- --------------------------END INCLUDED TEXT--------------------

You have received this e-mail bulletin as a result of your organisation's
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to auscert@auscert.org.au
and we will forward your request to the appropriate person.

NOTE: Third Party Rights
This security bulletin is provided as a service to AusCERT's members.  As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to follow or act on information or advice
contained in this security bulletin is the responsibility of each user or
organisation, and should be considered in accordance with your organisation's
site policies and procedures. AusCERT takes no responsibility for consequences
which may arise from following or acting on information or advice contained in
this security bulletin.

NOTE: This is only the original release of the security bulletin.  It may
not be updated when updates to the original are made.  If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the author's website to ensure that the information is still current.

Contact information for the authors of the original document is included
in the Security Bulletin above.  If you have any questions or need further
information, please contact them directly.

Previous advisories and external security bulletins can be retrieved from:


Australian Computer Emergency Response Team
The University of Queensland
Qld 4072

Internet Email: auscert@auscert.org.au
Facsimile:      (07) 3365 7031
Telephone:      (07) 3365 4417 (International: +61 7 3365 4417)
                AusCERT personnel answer during Queensland business hours
                which are GMT+10:00 (AEST).
                On call after hours for member emergencies only.
Comment: http://www.auscert.org.au/render.html?it=1967