Bug 1152789 - (CVE-2014-3566, POODLE) CVE-2014-3566 SSL/TLS: Padding Oracle On Downgraded Legacy Encryption attack
CVE-2014-3566 SSL/TLS: Padding Oracle On Downgraded Legacy Encryption attack
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
high Severity high
: ---
: ---
Assigned To: Red Hat Product Security
impact=important,public=20141014,repo...
: Reopened, Security
Depends On: 1152850 1152851 1152852 1152854 1152855 1152856 1152857 1153396 1153458 1153459 1153460 1153477 1153478 1153524 1153525 1153526 1154551 1154894 1154895 1159360 1160852 1160853 1161900 1168513 1168514 1168515 1168516 1168517 1168518 1169222 1384708 1384709 1384710 1384711 1384712 1384713
Blocks: 1152790 1153503 1153505 1153509 1155552 1168521 1179762 1241683 1384704
  Show dependency treegraph
 
Reported: 2014-10-14 20:49 EDT by Murray McAllister
Modified: 2016-11-21 03:14 EST (History)
117 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
A flaw was found in the way SSL 3.0 handled padding bytes when decrypting messages encrypted using block ciphers in cipher block chaining (CBC) mode. This flaw allows a man-in-the-middle (MITM) attacker to decrypt a selected byte of a cipher text in as few as 256 tries if they are able to force a victim application to repeatedly send the same data over newly created SSL 3.0 connections.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-11-20 21:32:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 1232233 None None None Never
Red Hat Knowledge Base (Article) 1232233 None None None Never
Red Hat Product Errata RHSA-2014:1652 normal SHIPPED_LIVE Important: openssl security update 2014-10-16 14:59:13 EDT
Red Hat Product Errata RHSA-2014:1653 normal SHIPPED_LIVE Moderate: openssl security update 2014-10-16 14:18:41 EDT
Red Hat Product Errata RHSA-2014:1692 normal SHIPPED_LIVE Important: openssl security update 2014-10-22 17:15:52 EDT
Red Hat Product Errata RHSA-2014:1876 normal SHIPPED_LIVE Critical: java-1.7.0-ibm security update 2014-11-19 18:32:13 EST
Red Hat Product Errata RHSA-2014:1877 normal SHIPPED_LIVE Critical: java-1.6.0-ibm security update 2014-11-19 18:32:00 EST
Red Hat Product Errata RHSA-2014:1880 normal SHIPPED_LIVE Critical: java-1.7.1-ibm security update 2014-11-20 16:31:54 EST
Red Hat Product Errata RHSA-2014:1881 normal SHIPPED_LIVE Important: java-1.5.0-ibm security update 2014-11-20 16:16:53 EST
Red Hat Product Errata RHSA-2014:1882 normal SHIPPED_LIVE Critical: java-1.7.0-ibm security update 2014-12-02 19:43:08 EST
Red Hat Product Errata RHSA-2014:1920 normal SHIPPED_LIVE Important: Red Hat JBoss Web Server 2.1.0 openssl security update 2014-12-01 19:23:56 EST
Red Hat Product Errata RHSA-2014:1948 normal SHIPPED_LIVE Important: nss, nss-util, and nss-softokn security, bug fix, and enhancement update 2014-12-02 23:03:42 EST
Red Hat Product Errata RHSA-2015:0010 normal SHIPPED_LIVE Important: Red Hat JBoss Enterprise Application Platform 5.2.0 security update 2015-01-05 21:32:25 EST
Red Hat Product Errata RHSA-2015:0011 normal SHIPPED_LIVE Important: Red Hat JBoss Enterprise Web Platform 5.2.0 security update 2015-01-05 21:32:18 EST
Red Hat Product Errata RHSA-2015:0012 normal SHIPPED_LIVE Important: Red Hat JBoss Enterprise Application Platform 6.3 openssl security update 2015-01-05 21:32:10 EST
Red Hat Product Errata RHSA-2015:0067 normal SHIPPED_LIVE Critical: java-1.7.0-openjdk security update 2015-01-21 21:45:27 EST
Red Hat Product Errata RHSA-2015:0068 normal SHIPPED_LIVE Important: java-1.7.0-openjdk security update 2015-01-20 22:38:26 EST
Red Hat Product Errata RHSA-2015:0069 normal SHIPPED_LIVE Important: java-1.8.0-openjdk security update 2015-01-21 21:38:44 EST
Red Hat Product Errata RHSA-2015:0079 normal SHIPPED_LIVE Critical: java-1.7.0-oracle security update 2017-12-15 10:35:56 EST
Red Hat Product Errata RHSA-2015:0080 normal SHIPPED_LIVE Critical: java-1.8.0-oracle security update 2017-12-15 10:34:38 EST
Red Hat Product Errata RHSA-2015:0085 normal SHIPPED_LIVE Important: java-1.6.0-openjdk security update 2015-01-26 18:10:42 EST
Red Hat Product Errata RHSA-2015:0086 normal SHIPPED_LIVE Important: java-1.6.0-sun security update 2017-12-15 10:35:12 EST
Red Hat Product Errata RHSA-2015:0264 normal SHIPPED_LIVE Low: Red Hat Satellite IBM Java Runtime security update 2015-02-24 13:44:15 EST
Red Hat Product Errata RHSA-2015:1545 normal SHIPPED_LIVE Important: node.js security update 2015-08-04 17:12:44 EDT
Red Hat Product Errata RHSA-2015:1546 normal SHIPPED_LIVE Important: node.js security update 2015-08-04 17:12:15 EDT

  None (edit)
Description Murray McAllister 2014-10-14 20:49:55 EDT
Bodo Möller, Thai Duong and Krzysztof Kotowicz of Google discovered a flaw in the design of SSL version 3.0 that would allow an attacker to calculate the plaintext of secure connections, allowing, for example, secure HTTP cookies to be stolen.

References:
http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html
https://www.openssl.org/~bodo/ssl-poodle.pdf
Comment 1 Murray McAllister 2014-10-14 20:55:26 EDT
Knowledgebase article:

https://access.redhat.com/articles/1232123

To mitigate this vulnerability, it is recommended that you explicitly disable SSLv3.0 in all affected packages. Additional instructions to do this for each affected package, as well as updates that disable SSLv3.0 by default, are being developed by Red Hat as a high priority.
Comment 3 Huzaifa S. Sidhpurwala 2014-10-14 23:41:30 EDT
NSS 3.17 already has a patch for this at:

https://hg.mozilla.org/projects/nss/rev/45cb71fd7bca
https://bugzilla.mozilla.org/show_bug.cgi?id=1036735

This introduces the SSL_ENABLE_FALLBACK_SCSV and resolves the downgrade issue.

This issue went into 3.17.1 beta
Comment 4 Huzaifa S. Sidhpurwala 2014-10-15 00:18:50 EDT
Created openssl tracking bugs for this issue:

Affects: fedora-all [bug 1152850]
Comment 5 Huzaifa S. Sidhpurwala 2014-10-15 00:18:56 EDT
Created mingw-openssl tracking bugs for this issue:

Affects: fedora-all [bug 1152851]
Comment 8 Nikos Mavrogiannopoulos 2014-10-15 02:37:18 EDT
(In reply to Huzaifa S. Sidhpurwala from comment #7)
> (In reply to Huzaifa S. Sidhpurwala from comment #3)
> 
> > GNUTLS:
> > Looks like gnutls already has support for SCSV. Need to figure out where
> 
> It appears like the following commit introduced SCSV in gnutls:
> 
> https://gitorious.org/gnutls/gnutls/commit/
> 1a338cbaaeec11d958de8da4d1ae036979fccf3e
> 
> Though i am confused why 0xff is used instead of 0x56. All rhels have this.

This is the TLS renegotiation SCSV which is different than the TLS fallback SCSV. However, the attack as I understand it does not apply on clients that rely on the TLS protocol negotiation. It applies to clients that do the "browser"-like negotiation which is to connect using TLS1.2, if that doesn't work, discard everything, and retry TLS 1.1... and so on until you do SSL 3.0.

GnuTLS does not provide an API to do that trickery, and does not even discuss that as an option. I think that this attack affects mostly browsers rather than applications that properly use TLS/SSL.
Comment 9 Huzaifa S. Sidhpurwala 2014-10-15 02:59:35 EDT
Statement:

This issue affects the version of openssl as shipped with Red Hat Enterprise Linux 5, 6 and 7, Red Hat JBoss Enterprise Application Platform 5 and 6, and Red Hat JBoss Web Server 1 and 2, Red Hat Enterprise Virtualization Hypervisor 6.5, and Red Hat Storage 2.1.

This issue affects the version of nss as shipped with Red Hat Enterprise Linux 5, 6 and 7.

Additional information can be found in the Red Hat Knowledgebase article: 
https://access.redhat.com/articles/1232123
Comment 10 Huzaifa S. Sidhpurwala 2014-10-15 03:12:11 EDT
IssueDescription:

A flaw was found in the way SSL 3.0 handled padding bytes when decrypting messages encrypted using block ciphers in cipher block chaining (CBC) mode. This flaw allows a man-in-the-middle (MITM) attacker to decrypt a selected byte of a cipher text in as few as 256 tries if they are able to force a victim application to repeatedly send the same data over newly created SSL 3.0 connections.
Comment 14 Tomas Hoger 2014-10-15 08:09:38 EDT
Note that there are two problems outlined in the paper linked in comment 0:

- efficient padding oracle attack against SSL 3.0 CBC cipher suites
- lack of ways to avoid MITM forced fallback in applications that implement re-connect SSL/TLS version fallback mechanism


The SSL 3.0 problem is yet another attack against the "authenticate-then-encrypt" constructions used by block ciphers in the cipher block chaining (CBC) mode, as used in SSL and TLS.  Previous attacks included BEAST / CVE-2011-3389 (bug 737506) or Lucky13 / CVE-2013-0169 (bug 907589).  The paper describes that when using SSL 3.0, only as little as 256 connections may be required to reliably decrypt one byte of cipher text.

The attack is similar to the BEAST attack - it requires that a man-in-the-middle (MITM) attacker can make victim SSL client to repeatedly send the same secret information over SSL connection, mixed with attacker provided data.  Web browser is an example of such use case.  Attacker's script can make victim's browser send repeated requests to a target server.  Each request containing attacker controlled data (such as target path and GET/POST data) as well as secret information attacker wants to recover (such as authentication cookie).  A more detailed description of the browser attack can be found in the Adam Langley's blog post:

https://www.imperialviolet.org/2014/10/14/poodle.html

SSL 3.0 protocol issues that allow this attack are addressed, to some degree, in TLS - TLS 1.0 specifies format of message padding bytes, newer TLS versions define cipher suites using different modes.

Implementations of SSL 3.0 protocols should be expected to get any fix to address this protocol problem.  Patches linked in comment 2 and comment 3 do not fix this issue, see below for more information on what they do.  One alternative may be to restrict use of CBC block ciphers with SSL 3.0, which leaves stream cipher RC4 as the only alternative.  RC4 has other known issues (see CVE-2013-2566 / bug 921947) and its use is discouraged.  It seems the only option will be to abandon the use of SSL 3.0.  See the Red Hat Knowledgebase article linked in comment 1 for instructions on how to disable the use of SSL 3.0 in various applications shipped as part of Red Hat products.

As SSL/TLS libraries used today usually support at least TLS version 1.0 (which is newer protocol version than SSL 3.0 despite having lower version number), often up to the currently latest TLS version 1.2, TLS 1.0 or newer is usually negotiated when SSL/TLS connection is created.  SSL/TLS protocols include a fallback mechanism which allows client and server to communicate even if the highest SSL/TLS version they support is not the same.  Client indicates the highest version it supports in its ClientHello handshake message, and server picks the highest version supported by both peers and communicates it back to client in its ServerHello handshake message.  SSL/TLS protocols implement protections to prevent MITM attacker from being able to tamper with handshake messages to force the use of the protocol version lower than the highest version supported by both client and server.  Which leads us to the second problem...


Certain applications, most notably web browsers such as Mozilla Firefox or Google Chrome, implement different fallback mechanism for compatibility reasons.  Some SSL/TLS implementation do not correctly handle cases when connecting client supports newer TLS protocol version than supported by the client, or when certain TLS extensions are used.  Instead of negotiating the highest TLS version supported by server, connection attempt may fail.  As a workaround, a web browser may attempt to re-connect with certain protocol versions disabled.  For example, browser may initially connect claiming TLS 1.2 as the highest supported version, and subsequently reconnect claiming only TLS 1.1, TLS 1.0 or eventually SSL 3.0 as the highest supported version until connection attempt succeeds.

This fallback mechanism makes it trivial for MITM attacker to force browser to use specific SSL/TLS version when talking to a web server.  Even if both client and server support TLS 1.2, they can be forced to use SSL 3.0 if both allow that protocol version, which makes it possible to mount a padding oracle attack as described above.

Patches in comment 2 and comment 3, which implement the TLS_FALLBACK_SCSV protection defined in the following RFC draft:

https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00

aims to make this fallback mechanism safer by making it possible for applications to indicate if they are doing version fallback and that they can speak newer SSL/TLS protocol version.  Note that those fixes are insufficient if only applied to SSL/TLS libraries, client applications need to be modified to take advantage of the new feature.  The following conditions must be met to make TLS_FALLBACK_SCSV protection work:

- SSL/TLS library used by an application doing re-connect fallback needs to implement TLS_FALLBACK_SCSV
- application must be modified to instruct the SSL/TLS library to send TLS_FALLBACK_SCSV when doing fallback to older protocol version
- SSL/TLS library used by the server must support TLS_FALLBACK_SCSV, no change to the server application is required

If server sees a connection attempt using SSL/TLS version lower than the highest protocol version it supports and that also includes TLS_FALLBACK_SCSV, it rejects the connection.

Note that is re-connect version fallback commonly found in web browsers is uncommon in other applications or SSL/TLS libraries (i.e. it is not done by OpenSSL, NSS or GnuTLS).
Comment 15 Tomas Hoger 2014-10-15 08:11:55 EDT
Regarding the CVE, Mitre CVE project currently describes CVE-2014-3566 as:

  The SSL protocol 3.0, as used in OpenSSL through 1.0.1i and other products,
  uses nondeterministic CBC padding, which makes it easier for man-in-the-
  middle attackers to obtain cleartext data via a padding-oracle attack, aka
  the "POODLE" issue.

This description pins the CVE to the first, SSL 3.0 protocol issue.  However, it seems to have been used for both problems, and as part of fixes adding TLS_FALLBACK_SCSV support, which is likely to create confusion.
Comment 17 Tomas Hoger 2014-10-15 15:41:39 EDT
OpenSSL upstream versions 0.9.8zc, 1.0.0o and 1.0.1j add support for TLS Fallback Signaling Cipher Suite Value (TLS_FALLBACK_SCSV) as a mitigation against CVE-2014-3566 / POODLE attack.

https://www.openssl.org/news/secadv_20141015.txt
Comment 22 Murray McAllister 2014-10-16 02:49:55 EDT
Jenkins is adding a code fix to disable SSLv3:

https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2014-10-15
Comment 38 Gerrit Slomma 2014-10-16 07:02:57 EDT
script is:

#!/bin/bash
#
#  Copyright (C) 2014 by Dan Varga
#  dvarga@redhat.com
#
#  This program is free software; you can redistribute it and/or modify
#  it under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 3 of the License, or
#  (at your option) any later version.


host=$1
port=$2

if [ "$2" == "" ]
then
        port=443
fi


out="`echo x | openssl s_client -ssl3 -connect ${host}:${port} 2>/dev/null`"
ret=$?

if [ $ret -eq 0 ]
then
        echo "VULNERABLE! SSLv3 detected."
        exit
elif [ $ret -eq 1 ]
then
        out=`echo $out | perl -pe 's|.*Cipher is (.*?) .*|$1|'`
        if [ "$out" == "0000" ] || [ "$out" == "(NONE)" ]
        then
                echo "Not Vulnerable. We detected that this server does not support SSLv3"
                exit
        else
                echo "just passing through..."
        fi
elif [ $ret -eq 124 ]
then
        echo "error: timeout connecting to host $host:$port"
        exit
fi
echo "error: Unable to connect to host $host:$port"

now results:

client runs openssl 0.9.8e-12.el5_4.6 on RHEL 5
server is jboss 4.2.2.GA with openssl 0.9.8e-12.el5_5.7 => VULNERABLE! SSLv3 detected.
server is jboss 5.1.0.GA with openssl 0.9.8e-26.el5_9.1 => VULNERABLE! SSLv3 detected.
server is jboss EAP6.1.0.GA with openssl 1.0.1e-16.el6_5.4 => VULNERABLE! SSLv3 detected.

client runs openssl 1.0.1e-16.el6_5.4 on RHEL 6(.5)
server is jboss 4.2.2.GA with openssl 0.9.8e-12.el5_5.7 => just passing through...
error: Unable to connect to host c0164673.prod.bfa:9443
server is jboss 5.1.0.GA with openssl 0.9.8e-26.el5_9.1 => just passing through...
error: Unable to connect to host c0164530.prod.bfa:9443
server is jboss EAP6.1.0.GA with openssl 1.0.1e-16.el6_5.4 => just passing through...
error: Unable to connect to host c0164530.prod.bfa:9443

however, this is yielded inside the script

# out=`echo x | openssl s_client -ssl3 -connect c0164529.prod.bfa:9443 2>/dev/null`;echo $out | perl -pe 's|.*Cipher is (.*?) .*|$1|'
ECDHE-RSA-AES256-SHA

and shorter:

# echo x | openssl s_client -ssl3 -connect c0164529.prod.bfa:9443 2>/dev/null;echo $?
CONNECTED(00000003)
(...certificate chain here...)
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : SSLv3
    Cipher    : ECDHE-RSA-AES256-SHA
    Session-ID: 543FA546602F970772A05828E981C983BB6058CA9127E9FB43EE6FB515734ADC
    Session-ID-ctx:
    Master-Key: 5FB4F48FEEA29FE469A7A4CAC52B6F90A91FA87EEBA6B5FDC560089FEF8CD56A0E2A835DAC4E97084DE02B8BD62A34F4
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1413457222
    Timeout   : 7200 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---
1


Is this fine? I am puzzled, the checker-script tells it is "unable to connect", yet there clearly "connected" is stated...
Comment 40 errata-xmlrpc 2014-10-16 10:19:37 EDT
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 5

Via RHSA-2014:1653 https://rhn.redhat.com/errata/RHSA-2014-1653.html
Comment 41 errata-xmlrpc 2014-10-16 10:59:27 EDT
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6
  Red Hat Enterprise Linux 7

Via RHSA-2014:1652 https://rhn.redhat.com/errata/RHSA-2014-1652.html
Comment 43 Tomas Hoger 2014-10-16 14:59:04 EDT
The openssl packages errata linked in comment 40 and comment 41 do not address the SSL 3.0 protocol issue, to which the CVE-2014-3566 was assigned.  They add support for the TLS_FALLBACK_SCSV, which enables TLS servers to detect forced protocol downgrades against clients that do re-connect protocol version fallback.  Both server and client need to implement this feature, and clients have to actively use it for the protection to work (see comment 14 for details).
Comment 44 Pankaj Sharma 2014-10-17 04:51:26 EDT
Tomas, we rely on the official releases by Red Hat and not on bugzilla comments by anyone..
Comment 45 Pankaj Sharma 2014-10-17 04:56:22 EDT
(In reply to Tomas Hoger from comment #43)
> The openssl packages errata linked in comment 40 and comment 41 do not
> address the SSL 3.0 protocol issue, to which the CVE-2014-3566 was assigned.
> They add support for the TLS_FALLBACK_SCSV, which enables TLS servers to
> detect forced protocol downgrades against clients that do re-connect
> protocol version fallback.  Both server and client need to implement this
> feature, and clients have to actively use it for the protection to work (see
> comment 14 for details).


Tomas, we rely on the official releases by Red Hat and not on bugzilla comments by anyone..btw, are you from redhat ?
Comment 46 john.haxby@oracle.com 2014-10-17 05:15:19 EDT
Tomas Hoger is in Red Hat Product Security.
Comment 47 Pankaj Sharma 2014-10-17 05:19:21 EDT
John, you are from oracle, how do you know that ? :-)
Comment 48 Dex 2014-10-17 10:58:03 EDT
A bit messy POODLE :)

At https://access.redhat.com/solutions/120383
in "Red Hat Enterprise Linux 5 (postfix-2.3.x)"
these setting are implemented in postfix 2.5, correct legacy syntax is:

smtpd_tls_mandatory_protocols = TLSv1
smtp_tls_mandatory_protocols = TLSv1

(In reply to errata-xmlrpc from comment #41)

There are no RHEL6 packages linked in RHSA-2014:1652
https://rhn.redhat.com/errata/RHSA-2014-1652.html

I guess RHEL6 was mentioned by mistake ?
Comment 49 Tomas Hoger 2014-10-17 11:17:13 EDT
(In reply to Dex from comment #48)
> There are no RHEL6 packages linked in RHSA-2014:1652
> https://rhn.redhat.com/errata/RHSA-2014-1652.html

The erratum lists openssl-1.0.1e-30.el6_6.2 as updated package for various Red Hat Enterprise Linux 6 variants.  Red Hat Enterprise Linux 6 is also in the list of Affected Products near the top of the page.
Comment 51 Vincent Danen 2014-10-20 13:42:52 EDT
Note that upstream python is disabling SSLv3 by default:

http://bugs.python.org/issue22638
Comment 52 Dex 2014-10-20 15:05:22 EDT
(In reply to Tomas Hoger from comment #49)
> (In reply to Dex from comment #48)
> > There are no RHEL6 packages linked in RHSA-2014:1652
> > https://rhn.redhat.com/errata/RHSA-2014-1652.html
> 
> The erratum lists openssl-1.0.1e-30.el6_6.2 as updated package for various
> Red Hat Enterprise Linux 6 variants.  Red Hat Enterprise Linux 6 is also in
> the list of Affected Products near the top of the page.

Both issues resolved .. thanks.
Comment 53 Murray McAllister 2014-10-20 21:21:12 EDT
With Asterisk AST-2014-011 advisory, SSLv3 is no longer used for res_jabber/res_xmpp, and when no encryption method is specified, it is no longer possible to fall back to SSLv3 or SSLv2:

http://downloads.asterisk.org/pub/security/AST-2014-011.html

(Fedora and EPEL bugs: bug 1154894, bug 1154895)
Comment 54 Murray McAllister 2014-10-22 01:00:40 EDT
libserf 1.3.8 disables SSLv2 and SSLv3:

https://serf.googlecode.com/svn/tags/1.3.8/CHANGES

(Fedora and EPEL bugs: bug 1155392, bug 1155393)
Comment 56 errata-xmlrpc 2014-10-22 13:16:42 EDT
This issue has been addressed in the following products:

  Red Hat Storage 2.1

Via RHSA-2014:1692 https://rhn.redhat.com/errata/RHSA-2014-1692.html
Comment 57 Vincent Danen 2014-11-05 14:34:49 EST
Asterisk is susceptible to this as well, as per upstream advisory http://downloads.asterisk.org/pub/security/AST-2014-011.html (it includes patches for Asterisk 11 (Fedora) and Asterisk 1.8 (EPEL 6)
Comment 58 Vincent Danen 2014-11-05 14:44:27 EST
Created asterisk tracking bugs for this issue:

Affects: fedora-all [bug 1160852]
Affects: epel-6 [bug 1160853]
Comment 59 Tomas Hoger 2014-11-06 05:23:54 EST
(In reply to Huzaifa S. Sidhpurwala from comment #3)
> NSS 3.17 already has a patch for this at:
> 
> https://hg.mozilla.org/projects/nss/rev/45cb71fd7bca
> https://bugzilla.mozilla.org/show_bug.cgi?id=1036735

Backport to 3.16:

https://hg.mozilla.org/projects/nss/rev/53506619e81a

Additional bug tracking addition of the TLS_FALLBACK_SCSV support to NSS utilities:

https://bugzilla.mozilla.org/show_bug.cgi?id=1083360
https://hg.mozilla.org/projects/nss/rev/34baf87d485d
Comment 60 Tomas Hoger 2014-11-11 07:59:08 EST
IBM Java SE updates 5.0 SR16-FP8, 6 SR16-FP2, 6R1 SR8-FP2, 7 SR8, and 7R1 SR2 address this issue by disabling SSL 3.0 by default.  Those updates also implement the following changes:

- Add new system property com.ibm.jsse2.disableSSLv3 that can be used to re-enable SSL 3.0 by setting its value to false.
- Change semantics of the SSLContext.getInstance("SSL") call - prior to this update, only SSL 3.0 was enabled.  In updated versions, TLS 1.0 and possibly 1.1 and 1.2 are enabled instead.

Details of the changes can be found in the following IBM article:

http://www-01.ibm.com/support/docview.wss?uid=swg21688165
Comment 61 Murray McAllister 2014-11-11 22:37:46 EST
Puppet advisory:

http://puppetlabs.com/blog/impact-assessment-sslv3-vulnerability-poodle-attack
Comment 62 errata-xmlrpc 2014-11-19 13:33:00 EST
This issue has been addressed in the following products:

  Supplementary for Red Hat Enterprise Linux 5
  Supplementary for Red Hat Enterprise Linux 6

Via RHSA-2014:1877 https://rhn.redhat.com/errata/RHSA-2014-1877.html
Comment 63 errata-xmlrpc 2014-11-19 13:33:55 EST
This issue has been addressed in the following products:

  Supplementary for Red Hat Enterprise Linux 5

Via RHSA-2014:1876 https://rhn.redhat.com/errata/RHSA-2014-1876.html
Comment 64 errata-xmlrpc 2014-11-20 11:19:21 EST
This issue has been addressed in the following products:

  Supplementary for Red Hat Enterprise Linux 6

Via RHSA-2014:1882 https://rhn.redhat.com/errata/RHSA-2014-1882.html
Comment 65 errata-xmlrpc 2014-11-20 11:34:18 EST
This issue has been addressed in the following products:

  Supplementary for Red Hat Enterprise Linux 6
  Supplementary for Red Hat Enterprise Linux 7

Via RHSA-2014:1880 https://rhn.redhat.com/errata/RHSA-2014-1880.html
Comment 66 errata-xmlrpc 2014-11-20 11:53:01 EST
This issue has been addressed in the following products:

  Supplementary for Red Hat Enterprise Linux 5
  Supplementary for Red Hat Enterprise Linux 6

Via RHSA-2014:1881 https://rhn.redhat.com/errata/RHSA-2014-1881.html
Comment 71 errata-xmlrpc 2014-12-01 14:24:07 EST
This issue has been addressed in the following products:

  JBoss Web Server 2.1.0

Via RHSA-2014:1920 https://rhn.redhat.com/errata/RHSA-2014-1920.html
Comment 72 errata-xmlrpc 2014-12-02 18:04:28 EST
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7
  Red Hat Enterprise Linux 6
  Red Hat Enterprise Linux 5

Via RHSA-2014:1948 https://rhn.redhat.com/errata/RHSA-2014-1948.html
Comment 73 Fedora Update System 2014-12-14 17:05:55 EST
nodejs-0.10.33-1.el7, libuv-0.10.29-1.el7 has been pushed to the Fedora EPEL 7 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 74 Fedora Update System 2014-12-14 17:06:56 EST
nodejs-0.10.33-1.el6, libuv-0.10.29-1.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 75 Fedora Update System 2014-12-14 23:31:52 EST
nodejs-0.10.33-1.fc21, libuv-0.10.29-1.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 76 Fedora Update System 2014-12-14 23:34:10 EST
nodejs-0.10.33-1.fc20, libuv-0.10.29-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 77 Fedora Update System 2014-12-14 23:35:27 EST
nodejs-0.10.33-1.fc19, libuv-0.10.29-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 79 errata-xmlrpc 2015-01-05 16:32:31 EST
This issue has been addressed in the following products:

  JBoss Enterprise Application Platform 6.3

Via RHSA-2015:0012 https://rhn.redhat.com/errata/RHSA-2015-0012.html
Comment 80 errata-xmlrpc 2015-01-05 16:32:50 EST
This issue has been addressed in the following products:

  JBoss Enterprise Web Platform 5.2.0

Via RHSA-2015:0011 https://rhn.redhat.com/errata/RHSA-2015-0011.html
Comment 81 errata-xmlrpc 2015-01-05 16:33:10 EST
This issue has been addressed in the following products:

  JBoss Enterprise Application Platform 5.2.0

Via RHSA-2015:0010 https://rhn.redhat.com/errata/RHSA-2015-0010.html
Comment 82 Tomas Hoger 2015-01-20 16:35:48 EST
The OpenJDK (IT6 1.13.6, IT7 2.5.4, and 8u31-b13) and Oracle JDK (5.0u81, 6u91, 7u75 and 8u31) updates address this issue by disabling SSL 3.0 protocol support by default.  Updates add support for disabling specific SSL/TLS protocol versions using the jdk.tls.disabledAlgorithms security property, and they also update the master security properties file, java.security, to add SSLv3 to the list of algorithms that are disabled by default.

Users who need to re-enable SSL 3.0 protocol support in OpenJDK or Oracle JDK can do so using one of the following ways:

* Change the master security properties file to not include SSLv3 in the list of disabled algorithms.  The java.security files for each JDK can be found at the following path:

  /usr/lib/jvm/*/jre/lib/security/java.security

The sub-directory under /usr/lib/jvm contains package name (such as java-1.7.0-openjdk or java-1.7.0-oracle) possibly followed by package version or architecture (depending on the JDK and its version).

Note that the change to the file will affect all applications using given JDK.  Local changes to the file will also cause new java.security versions to be installed as java.security.rpmnew if future updates change packaged version, requiring manual merge of changes.

* Re-enable SSLv3 support only for specific application or applications that require it.  Create a new security properties file that will override the default jdk.tls.disabledAlgorithms setting from the master java.security, and use the java.security.properties system property to make Java read the file in addition to the master security properties file.  Example:

  $ cat enable-ssl3.security 
  jdk.tls.disabledAlgorithms=

  $ java -Djava.security.properties=/path/to/enable-ssl3.security ...

Note that this only works if the master security properties file sets the security.overridePropertiesFile security property to true.  That is the default setting in all OpenJDK and Oracle JDK packages shipped in Red Hat Enterprise Linux.
Comment 83 errata-xmlrpc 2015-01-20 17:39:20 EST
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 5

Via RHSA-2015:0068 https://rhn.redhat.com/errata/RHSA-2015-0068.html
Comment 84 errata-xmlrpc 2015-01-21 17:45:53 EST
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6

Via RHSA-2015:0069 https://rhn.redhat.com/errata/RHSA-2015-0069.html
Comment 85 errata-xmlrpc 2015-01-21 17:58:52 EST
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6
  Red Hat Enterprise Linux 7

Via RHSA-2015:0067 https://rhn.redhat.com/errata/RHSA-2015-0067.html
Comment 87 errata-xmlrpc 2015-01-22 16:24:30 EST
This issue has been addressed in the following products:

  Oracle Java for Red Hat Enterprise Linux 6

Via RHSA-2015:0080 https://rhn.redhat.com/errata/RHSA-2015-0080.html
Comment 88 errata-xmlrpc 2015-01-22 16:35:05 EST
This issue has been addressed in the following products:

  Oracle Java for Red Hat Enterprise Linux 7
  Oracle Java for Red Hat Enterprise Linux 5
  Oracle Java for Red Hat Enterprise Linux 6

Via RHSA-2015:0079 https://rhn.redhat.com/errata/RHSA-2015-0079.html
Comment 90 errata-xmlrpc 2015-01-26 12:28:16 EST
This issue has been addressed in the following products:

  Oracle Java for Red Hat Enterprise Linux 7
  Oracle Java for Red Hat Enterprise Linux 6
  Oracle Java for Red Hat Enterprise Linux 5

Via RHSA-2015:0086 https://rhn.redhat.com/errata/RHSA-2015-0086.html
Comment 91 errata-xmlrpc 2015-01-26 13:12:06 EST
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 5
  Red Hat Enterprise Linux 6
  Red Hat Enterprise Linux 7

Via RHSA-2015:0085 https://rhn.redhat.com/errata/RHSA-2015-0085.html
Comment 93 errata-xmlrpc 2015-02-24 08:45:39 EST
This issue has been addressed in the following products:

  Red Hat Satellite Server v 5.6

Via RHSA-2015:0264 https://rhn.redhat.com/errata/RHSA-2015-0264.html
Comment 99 Hubert Kario 2015-04-27 07:38:00 EDT
Official workaround for the issue has been published by IETF as RFC 7507 "TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks".

https://tools.ietf.org/html/rfc7507
Comment 103 errata-xmlrpc 2015-08-04 13:12:27 EDT
This issue has been addressed in the following products:

  RHEL 6 Version of OpenShift Enterprise 2.0

Via RHSA-2015:1546 https://rhn.redhat.com/errata/RHSA-2015-1546.html
Comment 104 errata-xmlrpc 2015-08-04 13:12:54 EDT
This issue has been addressed in the following products:

  RHEL 6 Version of OpenShift Enterprise 2.1

Via RHSA-2015:1545 https://rhn.redhat.com/errata/RHSA-2015-1545.html

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