This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 737506 - (BEAST, CVE-2011-3389) CVE-2011-3389 HTTPS: block-wise chosen-plaintext attack against SSL/TLS (BEAST)
CVE-2011-3389 HTTPS: block-wise chosen-plaintext attack against SSL/TLS (BEAST)
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=moderate,public=20110910,repor...
: Security
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
Blocks: 737510 752378 784515
  Show dependency treegraph
 
Reported: 2011-09-12 07:20 EDT by Jan Lieskovsky
Modified: 2015-11-24 09:56 EST (History)
44 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-07-16 04:54:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Mozilla Foundation 665814 None None None Never
Mozilla Foundation 702111 None None None Never
Novell 719047 None None None Never

  None (edit)
Description Jan Lieskovsky 2011-09-12 07:20:31 EDT
Juliano Rizzo announced:
[1] 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 3 Josh Bressers 2011-09-22 13:51:03 EDT
Opera has assigned this issue CVE-2011-3389.
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 9 Mark J. Cox (Product Security) 2011-09-27 03:37:07 EDT
http://vnhacker.blogspot.com/2011/09/beast.html
Comment 11 Mark J. Cox (Product Security) 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-1.6.0.0-60.1.10.4.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 [5] 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
I recently read that "the BEAST attack is not feasible today."

Does this argument hold any water?

See: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk86440

Which states:

For the BEAST attack to succeed all of the following conditions must hold:

- SSLv3 or TLS 1.0 must be used.
- A block cipher must be used.
- The empty fragment mitigation must not be used. Many browsers, including
  IE and Chrome have it now.
- The attacker must be able to both run an agent on the browser, and to
  monitor outgoing traffic.
- The attacker must find a way to bypass the Same Origin Policy (SOP) on
  the browser, because the browser is not supposed to allow an attacker's
  agent (whether implemented in Java, Javascript, Flash or Silverlight) to
  send requests to another server.

The BEAST attack used a bug in the Java virtual machine implemented in some browsers, where the SOP was not enforced. This bug in Java has been fixed and all reasonably updated clients are not vulnerable. Similarly, all clients that have the empty fragment mitigation are not vulnerable either. In additional all other browser bugs mentioned in this CVE (e.g. WebSocket API) were fixed.

Therefore, the BEAST attack is not feasible today.
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

Note You need to log in before you can comment on or make changes to this bug.