POODLE: SSLv3 vulnerability (CVE-2014-3566)
Red Hat Product Security has been made aware of a vulnerability in the SSLv3 protocol, which has been assigned CVE-2014-3566 and commonly referred to as 'POODLE'. All implementations of SSLv3 are affected.
Background Information
POODLE stands for Padding Oracle On Downgraded Legacy Encryption. This vulnerability allows a man-in-the-middle attacker to decrypt ciphertext using a padding oracle side-channel attack. More details are available in the upstream OpenSSL advisory.
POODLE affects older standards of encryption, specifically Secure Socket Layer (SSL) version 3. It does not affect the newer encryption mechanism known as Transport Layer Security (TLS).
Impact
Avoiding Man-In-The-Middle Attacks
Exploiting this vulnerability is not easily accomplished. Man-in-the-middle attacks require large amounts of time and resources. While likelihood is low, Red Hat recommends implementing only TLS to avoid flaws in SSL.
Avoiding a Fallback Attack
Several vendors have provided patches to cryptographic libraries introducing a TLS Fallback Signaling Cipher Suite Value (TLS_FALLBACK_SCSV). This fallback mechanism allows clients to indicate to a server that they support newer SSL/TLS versions than those initially proposed. In the event of suspicious behavior where a client attempts to fallback to an older version when newer versions are supported, the server will abort the connection.
Currently, only HTTPs clients perform out-of-band protocol fallback.
Products that Red Hat support currently vulnerable from a client side perspective are:
- Firefox
- Chromium
- Curl command line tool and libraries
Currently, Google's Chromium is the only web based browser supported by Red Hat that will handle this functionality client side.
To avoid the fallback attack, supported browsers (only Chromium at this time) must interact with a server supporting TLS_FALLBACK_SCSV negotiation
The server side also needs to be patched to support SCSV extension, and does not need a rebuild with the patched crypto library. Again, due to current lack of support in most common web browsers, any changes server side will only be relevant when client based browsers support the more secure measures.
To learn more about the patched crypto libraries review RHSA-2014:1652-1 and RHSA-2014:1653-1
For non HTTPs clients:
Disabling SSLv3 in favor of at least a TLS connection is recommended. However in disabling SSL it is important to understand that certain applications that do not support TLS could default to plain-text transmission which would be worse from a security perspective than the vulnerable SSL protocol. Before disabling SSL on services, please carefully consider these measures.
Determining Vulnerability
Red Hat Support Subscribers
As a Red Hat customer the easiest way to check vulnerability and confirm remediation is the Red Hat Access Lab: SSLv3 (POODLE) Detector
Non Subscribers
If you are not a subscriber, the script attached to this article (poodle.sh) can be run against a server to check whether it has SSLv3 enabled.
NOTE: This script takes the hostname of the server to check as the first argument and an optional port as the second. By default it will check the local system and port 443.
Resolution
The following guides have been established to help disable SSLv3 for affected products. Red Hat is continuously working at this time to provide additional use cases and guides to disable SSLv3. Note that if you use a third-party service to terminate SSL/TLS connections, then SSLv3 needs to be disabled by the service. Changes on your systems are not necessary in this case.
| Product | Affected Component(s) |
|---|---|
| Red Hat Enterprise Linux | Tomcat, Firefox/Chromium, httpd, vsftpd, Dovecot/Postfix, sendmail, CUPS, other components |
| JBoss Enterprise Middleware | Tomcat/JBoss Web, httpd, EJB (EAP 5), EJB (EAP 6), JMS (EAP 5), Camel, Jetty, Karaf, Fuse, A-MQ |
| Red Hat Satellite | Satellite Configuration |
| Red Hat Certificate System | Tomcat |
| Inktank Ceph Enterprise | httpd |
| Red Hat Enterprise OpenShift | OpenShift Configuration , RHC client tools |
| Red Hat Enterprise Linux OpenStack Platform | httpd |
| Red Hat CloudForms | httpd |
| Red Hat Directory Server | Directory Server Configuration |
| Red Hat Enterprise Virtualization | RHEV-M |
| Red Hat JBoss Enterprise Application Platform | EJB 5, EJB 6, JMS 5 |
| Red Hat Storage Console | httpd |
| Red Hat Update Infrastructure | pulp, httpd |
For More Information
If you have questions or concerns, please contact Red Hat Technical Support
24 Comments
Hello all,
I use applications Smtp/Imap/Pop and we are using SSLv3, use in postfix 2.6
what do you suggest to solve this BUG without going back to v2?
Hello Gilberto, please see the article Resolution for POODLE SSL 3.0 vulnerability (CVE-2014-3566) in Postfix and Dovecot, which documents how to disable SSL 3.0 and SSL 2.0 in Postfix. Hope this helps!
Martin, thanks for the brief reply, had not seen that link.
basically would force the TLS right? due to internal business rule is likely that we will have to force TLS 1.0
Thanks for your help.
Hi Martin,
stop kidding, the article is just a big joke regarding RHEL 5.
Actually there's no RH bugfix available which provides an secure operating system for a public mail server.
A very important notice is missing on the statements for postfix 2.3 on RHEL 5 and smtpd_tls_mandatory_protocols, smtp_tls_mandatory_protocols and smtp_enforce_tls:
It's only for mandatory TLS.
This is comparable to SMTP over TLS (smtps).
Using mandatory TLS for public mail server breaks RFS 2487:
A publicly-referenced SMTP server MUST NOT require use of the
STARTTLS extension in order to deliver mail locally. This rule
prevents the STARTTLS extension from damaging the interoperability of
the Internet's SMTP infrastructure. A publicly-referenced SMTP server
is an SMTP server which runs on port 25 of an Internet host listed in
the MX record (or A record if an MX record is not present) for the
domain name on the right hand side of an Internet mail address.
You can't run RHEL 5 with postfix in opportunistic TLS mode. Is this correct?
BTW - regarding smtp_enforce_tls you can read on postfix.org:
"With Postfix 2.3 and later use smtp_tls_security_level instead."
.
Does anyone know how to restrict SSLv3 for HP SIM?
I've modified "/opt/hp/hpsmh/conf/smhpd.conf" SSLProtocol All -SSLv2 -SSLv3. But when I restart "hpsmhd" it overwrites the changes. I don't see any parameter in "/opt/hp/hpsmh/conf/smhpd.xml" either.
sendmail?
Now I'm waiting for more than one week that RH provides an updated package of postfix for RHEL 5 (some customers still use RHEL 5 for public mail servers). But there isn't a poodle update for postfix until now.
Now I fixed it by myself.
If you are interested in it then please take a look at
RHEL 5 postfix poodle patch.
I need to fix this vulnerability en RHE 5.x and RHE 6.5. There is patch for poodle yet ??? Disable SSL3 editing httpd config is enough ???
To disable SSLv3 from HPSMH (HP System Management Homepage) make sure you are running at least version 7.3.3-1 and run the following as 'root'.
This will ensure SSLv3 is disabled and will not be overwritten on service restart.
James,
somehow I'm unable to reply to you last comment.
My "/opt/hp/hpsmh/conf/smhpd.conf" file has below entry. I do see some additional options which you don't have in your command line.
Is it ok if I use your command to disable SSLv3? I don't want to loose other restrictions I've.
SSLCipherSuite ALL:!ADH:!EXPORT56:!EXPORT40:DES-CBC3-SHA:RC4-MD5:RC4-SHA:RC4+RSA:+HIGH:+MEDIUM:-SSLv2:+EXP:!LOW:!eNULL:!aNULL
Parag,
As long as you're running hpsmh-7.3.3-1 or newer you should be able to simply add "-SSLv3" to whatever your current SSLCipherSuite has configured. My installed systems of hpsmh-7.3.3-1 and newer only contained the Ciphers I listed. Yours may be different depending on whether they were upgraded over time or fresh installs, etc.
So your command line options would look something like:
It's imperative you escape all of the exclamation marks (!) at the command line or it will complain.
You can not simply edit the smhpd.conf file directly as it will be overwritten during a service restart. You sill need to edit the Cipher list using the "smhconfig" command and whatever list of Ciphers you want configured as I outlined.
[root@lpwtest1 conf]# rpm -qa | grep hpsmh
hpsmh-7.4.0-13
I've tried that but it doesn't work.
[root@lpwtest1 conf]# /opt/hp/hpsmh/sbin/smhconfig --ssl-cipher-suite=ALL:!ADH:!EXPORT56:!EXPORT40:DES-CBC3-SHA:RC4-MD5:RC4-SHA:RC4+RSA:+HIGH:+MEDIUM:-SSLv2:-SSLv3:+EXP:!LOW:!eNULL:!aNULL
[root@lpwtest1 conf]# grep SSLCipherSuite smhpd.conf
SSLCipherSuite ALL:!ADH:!EXPORT56:!EXPORT40:RC4+RSA:+HIGH:+MEDIUM:-SSLv2:-SSLv3:+EX
Nerver mind, it's working
Thanks
I updated the openssl package on my server but poddle.sh is still showing
Vulnerable! SSLv3 connection established using SSLv3/DHE-RSA-AES256-SHA
why is that? Am I missing something with the usage of the script
Hi there Doug,
Updating openssl package on your server will not fix the POODLE vulnarability. The openssl errata does introduce TLS Fallback Signaling Cipher Suite Value (TLS_FALLBACK_SCSV). This fallback mechanism allows clients to indicate to a server that they support newer SSL/TLS versions than those initially proposed. In the event of suspicious behavior where a client attempts to fallback to an older version when newer versions are supported, the server will abort the connection.
In order to avoid being vulnerable against POODLE you'll need to disable SSLv3 for all your services running on the system in question.
Please carefully read the above article, which will provide more background information as well as information on how to disable SSLv3 for products shipped by Red Hat
Hello everyone.,
In relation to an SMTP server, To Mitigate/Complicate this vulnerability can also deactivate the ciphers weak, Right?
example: RC4-MD5, EDH-RSA-DES-CBC3-SHA, DES-CBC3-SHA, DHE-RSA-AES128-SHA, AES128-SHA
The RedHat have any remarks/Objection about it?
if i upgraded to this version shall it will solve this issue or not
openssl x86_64 1.0.1e-30.el6_6.4 rhel-x86_64-server-6 1.5 M
openssl-devel x86_64 1.0.1e-30.el6_6.4 rhel-x86_64-server-6 1.2 M
Hello "Technical Support",
you should not just install openssl from RHEL 6 because this will break many dependencies. Many applications and libs which need the RHEL 5 package and are compiled against this package wll not work properly anymore if you do a "hard" replacement.
The best way is to disable SSLv3 usage in all applications just like Red Hat recommends.
The "final solution" is throwing out the SSLv3 code out of openssl but doing this you won't get RHEL support.
If your skills are "advanced" then the best solution is to
a) rebuild openssl-0.98 package without SSLv3 (caution! openssl is crappy software! just disabling "SSL3" on "configure" will also disable all ssl3/tls1 cipher suites because the "programmers" did mix up protocols and cipher suites!)
b) and build/install a supplementary package with openssl 1.x to provide modern ciphers and protocols.
For more information please take a look at http://www.tuxad.de/blog/archives/2014/11/19/openssl_updatesenhancements_for_rhel__centos_5/index.html
regards,
Frank Bergmann
Hi there Technical Support,
Updating openssl package on your server will not fix the POODLE vulnarability. The openssl errata does introduce TLS Fallback Signaling Cipher Suite Value (TLS_FALLBACK_SCSV). This fallback mechanism allows clients to indicate to a server that they support newer SSL/TLS versions than those initially proposed. In the event of suspicious behavior where a client attempts to fallback to an older version when newer versions are supported, the server will abort the connection.
In order to avoid being vulnerable against POODLE you'll need to disable SSLv3 for all your services running on the system in question.
Please carefully read the above article, which will provide more background information as well as information on how to disable SSLv3 for products shipped by Red Hat
On the 'Hardening TLS Configuration' ( https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Security_Guide/index.html#sec-Hardening_TLS_Configuration) I still see TLS being recommended however I don’t see any reference to the TLS weakness mentioned on the Redhat article above, in fact it specifically says TLS is not affected ‘POODLE affects older standards of encryption, specifically Secure Socket Layer (SSL) version 3. It does not affect the newer encryption mechanism known as Transport Layer Security (TLS).’
Qualys Article: Poodle Bites TLS (https://community.qualys.com/blogs/securitylabs/2014/12/08/poodle-bites-tls)
Redhat Article: POODLE: SSLv3.0 vulnerability (CVE-2014-3566) (https://access.redhat.com/articles/1232123)
TLS 1.0 and later is not affected by the CBC padding vulnerability that is part of POODLE. Some TLS implementations however re-used SSL 3.0 unpadding code to also remove padding when using TLS without implementing padding checks as defined in the TLS specification. That is the issue described in the Qualys blog post.
However, it is an implementation issue rather than protocol issue. It makes affected TLS implementations vulnerable to the SSL 3.0 POODLE flaw, but it is not a reason to abandon TLS. Affected implementations need to be fixed to properly implement the specification to resolve the problem.
TLS libraries in Red Hat Enterprise Linux are not affected by this issue. See the statement for CVE-2014-8730.
HI Support,
Is there any fix available for this for RHEL5/6.
Thanks,
Bala
Hi Andreas,
The recommended way to "fix" this is to stop using SSLv3. SSLv3 (and lower) is now considered insecure and should not be used. The article contains links to instructions how to disable SSLv3 in a variety of components. These instructions are for RHEL 5, 6, and 7 (as well as a number of other products).
For example, to disable SSLv3 in the
httpdserver, see Resolution for POODLE SSLv3.0 vulnerability (CVE-2014-3566) in httpd. The solution includes instructions for both RHEL 5 and 6 (and 7).Pages