Red Hat Bugzilla – Full Text Bug Listing
|Summary:||CVE-2011-3389 HTTPS: block-wise chosen-plaintext attack against SSL/TLS (BEAST)|
|Product:||[Other] Security Response||Reporter:||Jan Lieskovsky <jlieskov>|
|Component:||vulnerability||Assignee:||Red Hat Product Security <security-response-team>|
|Status:||CLOSED ERRATA||QA Contact:|
|Version:||unspecified||CC:||aph, bhoefer, bressers, cschalle, djorm, emaldona, huzaifas, itamar, jbainbri, jorton, jreznik, jvanek, kchamart, kdudka, kengert, kevin, kevin, lmacken, ltinkl, martin.sourada, mathstuf, maurizio.antillon, mcepl, mclasen, mjc, mmello, mtasaka, mvanderw, pcfe, pinto.elia, rbinkhor, rdieter, rms, rnovacek, rsawhill, saiena, smparrish, stransky, than, tmraz, vdanen, walters, wnefal+redhatbugzilla|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2014-07-16 04:54:50 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:||744786, 744787, 744788, 744789, 744819, 744820, 744822, 769184, 769185, 769186, 769324, 769325, 769326, 769327, 769328, 784487, 784488, 784489, 784490, 814225, 814226, 814227, 814228|
|Bug Blocks:||737510, 752378, 784515|
Description Jan Lieskovsky 2011-09-12 07:20:31 EDT
Juliano Rizzo announced:  http://www.ekoparty.org/2011/juliano-rizzo.php that at ekoparty Security Conference, from 2011-09-21 to 2011-09-23 they will present a new fast block-wise chosen-plaintext attack against SSL/TLS. One application of the attack should allow the adversary to efficiently decrypt and obtain authentication tokens and cookies from HTTPS requests. The Red Hat Security Response Team is watching progress on this one and once further details are available, we will immediately react to ensure timely manner updates for affected packages.
Comment 1 Jan Lieskovsky 2011-09-21 06:37:17 EDT
Further references:  http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/  https://bugzilla.novell.com/show_bug.cgi?id=719047  http://eprint.iacr.org/2006/136 Countermeasures in openssl (from ):  http://www.openssl.org/~bodo/tls-cbc.txt  http://cvs.openssl.org/chngview?cn=6452
Comment 6 Josh Bressers 2011-09-25 11:54:35 EDT
This issue is now public. The best writeup I've seen is here: http://www.educatedguesswork.org/2011/09/security_impact_of_the_rizzodu.html
Comment 11 Mark J. Cox 2011-09-27 07:17:36 EDT
Statement: Red Hat is aware of, and tracking, the Rizzo/Duong chosen plain text attack on SSL/TLS 1.0, also known as "BEAST". This issue has been assigned CVE-2011-3389. This attack uses web browser extensions to exploit a weakness in SSL/TLS cipher-block chaining (CBC), allowing a man-in-the-middle attacker to recover certain session information, such as cookie data, from what should be a secure connection. The research shows two ways that an attacker could mount an attack. In both cases the attacker needs access to the data stream from the web browser to the server while a user visits a malicious website using a browser. The attacker may then be able to determine a portion of the data the browser sends to the server by making a large number of requests over a period of time. This data could include information such as an authentication cookie. The first method of attack involves using WebSockets. Currently, Red Hat does not ship any products that allow an attack using WebSockets to be successful. We are planning to update Firefox to version 7, which contains protections in the WebSocket code that prevents this particular attack from being effective. The second method of attack involves using a malicious Java applet. In order for the attack to be successful, the attacker would need to circumvent the Same Origin Policy (SOP) controls in Java. The researchers claim to have found a flaw in the Java SOP and we will issue updates to correct this flaw as suitable fixes are available. We are in contact with various upstream projects regarding this attack. As a precautionary measure, we plan to update the Network Security Services (NSS), GnuTLS, and OpenSSL packages as suitable fixes are available. We will continue to track this issue and take any appropriate actions as needed. This statement and any updates to it is available at: https://bugzilla.redhat.com/show_bug.cgi?id=737506
Comment 13 Vincent Danen 2011-09-27 19:52:48 EDT
GnuTLS has a mention of this via GNUTLS-SA-2011-1: http://www.gnu.org/software/gnutls/security.html Recommendation: Make use of TLS 1.1 or TLS 1.2 protocols that are not vulnerable to the attack. TLS 1.1 is included in GnuTLS since version 1.1.3 (released in 2003). If this is not possible, disable CBC ciphers.
Comment 16 errata-xmlrpc 2011-10-18 19:26:43 EDT
This issue has been addressed in java-1.6.0-openjdk packages in following products: Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 5 Via RHSA-2011:1380 https://rhn.redhat.com/errata/RHSA-2011-1380.html
Comment 17 errata-xmlrpc 2011-10-19 13:23:09 EDT
This issue has been addressed in java-1.6.0-sun packages in following products: Supplementary for Red Hat Enterprise Linux 6 Supplementary for Red Hat Enterprise Linux 5 Extras for Red Hat Enterprise Linux 4 Via RHSA-2011:1384 https://rhn.redhat.com/errata/RHSA-2011-1384.html
Comment 18 Fedora Update System 2011-11-04 21:26:45 EDT
java-1.6.0-openjdk-220.127.116.11-18.104.22.168.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
Comment 19 Tomas Hoger 2011-11-08 09:14:13 EST
OpenJDK (RHSA-2011:1380) and Oracle JDK (RHSA-2011:1384) updates mentioned above (comment #16 and comment #17) add a mitigation similar to the one available in OpenSSL (see  in comment #1). For better compatibility with some SSL/TLS implementations, it does not use 0/n split, but 1/(n-1) split, as discussed in the Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=665814#c89 Even this approach is known to cause certain compatibility issues and hence its use can be controlled using newly introduced property jsse.enableCBCProtection. The mitigation is enabled by default.
Comment 20 errata-xmlrpc 2012-01-09 15:08:29 EST
This issue has been addressed in java-1.4.2-ibm packages in following products: Extras for Red Hat Enterprise Linux 4 Supplementary for Red Hat Enterprise Linux 5 Via RHSA-2012:0006 https://rhn.redhat.com/errata/RHSA-2012-0006.html
Comment 21 errata-xmlrpc 2012-01-18 14:25:35 EST
This issue has been addressed in java-1.6.0-ibm packages in following products: Extras for Red Hat Enterprise Linux 4 Supplementary for Red Hat Enterprise Linux 5 Supplementary for Red Hat Enterprise Linux 6 Via RHSA-2012:0034 https://rhn.redhat.com/errata/RHSA-2012-0034.html
Comment 23 Tomas Hoger 2012-02-03 02:34:00 EST
Mozilla bug tracking issues of server intolerant to 1/n-1 record splitting: https://bugzilla.mozilla.org/show_bug.cgi?id=702111
Comment 25 Vincent Danen 2012-02-24 15:55:57 EST
Note that python is affected by this flaw as well: http://bugs.python.org/issue13885 http://hg.python.org/cpython/rev/9a4131ada792
Comment 26 errata-xmlrpc 2012-02-29 09:48:21 EST
This issue has been addressed in java-1.4.2-ibm-sap packages in following products: Red Hat Enterprise Linux 4 for SAP Red Hat Enterprise Linux 5 for SAP Red Hat Enterprise Linux 6 for SAP Via RHSA-2012:0343 https://rhn.redhat.com/errata/RHSA-2012-0343.html
Comment 29 errata-xmlrpc 2012-04-23 13:03:39 EDT
This issue has been addressed in java-1.5.0-ibm packages in following products: Supplementary for Red Hat Enterprise Linux 5 Supplementary for Red Hat Enterprise Linux 6 Via RHSA-2012:0508 https://rhn.redhat.com/errata/RHSA-2012-0508.html
Comment 30 Tomas Hoger 2012-05-17 12:07:01 EDT
Few write-ups discussing various countermeasures for this issue and their efficiency, as well as providing some practical example for mod_ssl: http://www.educatedguesswork.org/2011/11/rizzoduong_beast_countermeasur.html https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls
Comment 34 Tomas Hoger 2012-07-10 05:56:27 EDT
A mitigation for this flaw was implemented in the Network Security Services (NSS) library. It uses 1/(n-1) record splitting as mentioned in comment #19. This mitigation was added in NSS version 3.13 (which is used in Firefox 9 and later) and is enabled by default upstream. Environment variable NSS_SSL_CBC_RANDOM_IV can be used to disable the mitigation when it causes failures to connect to servers that are intolerant to such record splitting (see comment #23). Setting the environment variable value to 0 disables the mitigation. The nss packages in Red Hat Enterprise Linux 5 and 6 were updated to version 3.13.1 via RHBA-2012:0337: https://rhn.redhat.com/errata/RHBA-2012-0337.html Unlike upstream versions, this mitigation is disabled by default in nss packages in Red Hat Enterprise Linux 5 and 6 (which is the reason why RHBA-2012:0337 is not a security erratum and does not claim to fix this issue) and current Fedora versions (up to and including Fedora 17). References: https://bugzilla.redhat.com/show_bug.cgi?id=770682#c11 http://pkgs.fedoraproject.org/gitweb/?p=nss.git;a=commitdiff;h=40928cb8e33ef2b3cc7adc988f87fa36e7f00261 The mitigation can be enabled by setting NSS_SSL_CBC_RANDOM_IV environment variable value to 1. Future updates may change this default and enable the mitigation by default.
Comment 36 Tomas Hoger 2012-11-13 07:56:12 EST
(In reply to comment #34) > The mitigation can be enabled by setting NSS_SSL_CBC_RANDOM_IV environment > variable value to 1. Future updates may change this default and enable the > mitigation by default. This mitigation is enabled by default in Firefox and Thunderbird packages in Red Hat Enterprise Linux 5 and 6 starting with updates in RHSA-2012:1088 and RHSA-2012:1089: https://rhn.redhat.com/errata/RHSA-2012-1088.html https://rhn.redhat.com/errata/RHSA-2012-1089.html
Comment 37 Tomas Hoger 2012-11-13 08:30:34 EST
Quick summary of mitigation options for this issue: - Disable support for TLS 1.0 and older, require TLS 1.1 or later. This solution is still not widely usable, as TLS 1.1+ support and use is still limited. OpenSSL and NSS versions in Red Hat Enterprise Linux 5 and 6 currently do not support TLS 1.1 or later. Update: OpenSSL packages in Red Hat Enterprise Linux 6, and NSS packages in Red Hat Enterprise Linux 5 and 6 now support TLS 1.1 and 1.2, see comment 44 and comment 45 below for details. - Restrict the set of allowed cipher suites to only those that use stream cipher and are unaffected by this issue. Cipher suites using RC4 are commonly supported by SSL/TLS implementations. This may not be a usable workaround in environments where specific ciphers are required (such as AES). It is possible to configure httpd's mod_ssl to prefer RC4 whenever client (browser) supports it, even when client prefers different cipher suite (the default behavior is to honor client's cipher suite preference and use the first one supported by both client and server). Quoting example configuration from Qualys blog post (see comment #30): SSLHonorCipherOrder On SSLCipherSuite RC4-SHA:HIGH:!aNULL Refer to httpd documentation for detailed description of these configuration options: http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslhonorcipherorder http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslciphersuite Note that the above setting may still allow the use of block cipher when client does not support RC4-SHA. Only specifying single "SSLCipherSuite RC4-SHA" will require RC4, and will not establish connection with clients that do not implement it. Also note that the SSLHonorCipherOrder configuration option is not available in the httpd version in Red Hat Enterprise Linux 4. Update: The use of RC4 as preferred cipher is no longer encouraged, as attacks against this cipher were discovered, see bug 921947 for details. - Record splitting (either 0/n or 1/(n-1)). Such mitigation is implemented in both OpenSSL and NSS, but is not enabled by default due to known issues (see comment #23). This mitigation only protects one direction of the SSL/TLS communication (form the peer that implements the mitigation). It is enabled by default in the default web browser shipped with Red Hat Enterprise Linux (see comment #36), protecting the browser -> web server communication that was targeted by this attack. Enabling this mitigation on the server side will not protect communication from a browser. Update: This mitigation was implemented in most major web browsers and is considered sufficient protection against BEAST attack in environments where TLS 1.1 or later can not be used. The following blog post describes that Qualys' SSL Server Test no longer lowers score based on lack of server-side BEAST mitigatons: https://community.qualys.com/blogs/securitylabs/2013/09/10/is-beast-still-a-threat
Comment 38 Rui Miguel Seabra 2013-03-15 05:22:01 EDT
URGENT: The mitigation for OpenSSL is no longer valid, it's been proven insecure * Technical details by (the) Dan J. Bernstein: http://cr.yp.to/talks/2013.03.12/slides.pdf * Bla bla for those who need it spelled out in plain english http://www.forbes.com/sites/andygreenberg/2013/03/13/cryptographers-show-mathematically-crackable-flaws-in-common-web-encryption/ This affects everything built against OpenSSL like, for instance, merely httpd's mod_ssl? I'd say it should get more priority...
Comment 39 Huzaifa S. Sidhpurwala 2013-03-15 05:24:39 EDT
(In reply to comment #38) > URGENT: The mitigation for OpenSSL is no longer valid, it's been proven > insecure > > * Technical details by (the) Dan J. Bernstein: > > http://cr.yp.to/talks/2013.03.12/slides.pdf > > * Bla bla for those who need it spelled out in plain english > > http://www.forbes.com/sites/andygreenberg/2013/03/13/cryptographers-show- > mathematically-crackable-flaws-in-common-web-encryption/ > > This affects everything built against OpenSSL like, for instance, merely > httpd's mod_ssl? > > I'd say it should get more priority... Hi Rui, This is a different flaw, it concerns RC4.
Comment 40 Rui Miguel Seabra 2013-03-15 08:01:24 EDT
Yes, but RC4 is the mitigation for beast with OpenSSL. Please read comment 37.
Comment 41 Stephen 2013-04-03 16:19:30 EDT
Comment 43 errata-xmlrpc 2013-10-23 12:59:57 EDT
This issue has been addressed in following products: Red Hat Network Satellite Server v 5.4 Via RHSA-2013:1455 https://rhn.redhat.com/errata/RHSA-2013-1455.html
Comment 44 Huzaifa S. Sidhpurwala 2014-01-23 01:20:01 EST
(In reply to Tomas Hoger from comment #37) > Quick summary of mitigation options for this issue: > > - Disable support for TLS 1.0 and older, require TLS 1.1 or later. This > solution is still not widely usable, as TLS 1.1+ support and use is still > limited. OpenSSL and NSS versions in Red Hat Enterprise Linux 5 and 6 > currently do not support TLS 1.1 or later. > TLS 1.1 and TLS 1.2 are now enabled in the version of openssl as shipped with Red Hat Enterprise Linux 6.5 via: https://rhn.redhat.com/errata/RHBA-2013-1585.html Similarly, TLS 1.1 and TLS 1.2 are enabled in the version of nss as shipped with Red Hat Enterprise Linux 5 and 6. NSS 3.14 introduces support for TLS 1.1 NSS 3.15.1 introduces support for TLS 1.2
Comment 45 Tomas Hoger 2014-07-16 04:19:53 EDT
(In reply to Huzaifa S. Sidhpurwala from comment #44) > Similarly, TLS 1.1 and TLS 1.2 are enabled in the version of nss as shipped > with Red Hat Enterprise Linux 5 and 6. > > NSS 3.14 introduces support for TLS 1.1 Upstream release notes: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.14_release_notes The nss packages in Red Hat Enterprise Linux 5 and 6 were updated to NSS 3.14 or later via 5.10 and 6.4 respectively: https://rhn.redhat.com/errata/RHBA-2013-1318.html https://rhn.redhat.com/errata/RHBA-2013-0445.html > NSS 3.15.1 introduces support for TLS 1.2 Upstream release notes: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.15.1_release_notes The nss packages in Red Hat Enterprise Linux 5 and 6 were updated to NSS 3.15 or later after 5.10 and in 6.5 respectively: https://rhn.redhat.com/errata/RHSA-2013-1791.html https://rhn.redhat.com/errata/RHBA-2013-1558.html