OpenSSL CCS Injection Vulnerability (CVE-2014-0224) Alert

Updated -

Red Hat was recently notified of a vulnerability affecting all versions of OpenSSL shipped with Red Hat products. CVE-2014-0224 could allow for a man-in-the-middle attack against an encrypted connection.

SSL/TLS connections typically allow for encrypted traffic to pass between two parties where only the intended senders and recipients can decrypt data. In the event of a man-in-the-middle attack, an attacker could intercept an encrypted data stream allowing them to decrypt, view and then manipulate said data.

The vulnerability can only be exploited if both server and client are vulnerable to this issue. In the event that one of the two is vulnerable, there is no risk of exploitation.

NOTE: This vulnerability cannot be used to extract server or client side key material. This means that existing signed certificates do not need replacement once software is updated.

How does this impact systems

This issue affects products using OpenSSL.

All versions prior to those listed as updates for this issue are vulnerable to some degree.

See the appropriate remediation article for specifics.

Products Affected:

Product/Channel Affecting Fixed in package Remediation details
Red Hat Enterprise Linux 7 openssl-1.0.1e openssl-1.0.1e-34.el7_0.3 Red Hat Enterprise Linux
openssl098e openssl098e-0.9.8e-29.el7_0.2
Red Hat Enterprise Linux 6 openssl-1.0.1e openssl-1.0.1e-16.el6_5.14 Red Hat Enterprise Linux
openssl098e openssl098e-0.9.8e-18.el6_5.2
openssl-1.0.0 openssl-1.0.1e-16.el6_5.14
Red Hat Storage 2.1 openssl-1.0.1e openssl-1.0.1e-16.el6_5.14 Red Hat Storage 2.1
Red Hat Enterprise Virtualization openssl-1.0.1e openssl-1.0.1e-16.el6_5.14 Red Hat Enterprise Virtualization
Red Hat Enterprise Linux 5 openssl-0.9.8e openssl-0.9.8e-27.el5_10.3 Red Hat Enterprise Linux
openssl-0.9.8b openssl-0.9.8e-27.el5_10.3
openssl097a openssl097a-0.9.7a-12.el5_10.1
Red Hat Enterprise Linux 4 Extended Lifecycle Support openssl-0.9.7a openssl-0.9.7a-43.22.el4 Red Hat Enterprise Linux
Red Hat Enterprise Linux 5.6 Long Life

openssl-0.9.8e openssl-0.9.8e-12.el5_6.12 Red Hat Enterprise Linux
Red Hat Enterprise Linux 5.9 Extended Update Support

openssl-0.9.8e openssl-0.9.8e-26.el5_9.4 Red Hat Enterprise Linux
Red Hat Enterprise Linux 6.2 Advanced Update Support

openssl-1.0.0 openssl-1.0.0-20.el6_2.7 Red Hat Enterprise Linux
Red Hat Enterprise Linux 6.3 Extended Update Support openssl-1.0.0 openssl-1.0.0-25.el6_3.3 Red Hat Enterprise Linux
Red Hat Enterprise Linux 6.4 Extended Update Support openssl-1.0.0 openssl-1.0.0-27.el6_4.4 Red Hat Enterprise Linux
Red Hat JBoss Middleware products JBoss EAP 5.2   Red Hat JBoss Middleware
JBoss EAP 6.2 CP03 / 6.2 CP03
JBoss EWS 2.0.1
JBoss EWP 5.2

Since any machine in the product classes listed above cannot determine whether a connection it makes as a client is to a vulnerable server the only prudent solution is to ensure that any machine running a vulnerable version is updated.

Frequently Asked Questions

This FAQ is for the vulnerability CVE-2014-0224 in OpenSSL, also known as "CCS Injection".

Is this issue the same as HeartBleed?

No, this a new issue discovered in OpenSSL that could result in a man-in-the-middle attack. See the explanation above for full details.

Is this issue worse than HeartBleed?

HeartBleed allowed anyone on the internet to exploit vulnerable servers. This issue requires an attacker to intercept and alter network traffic in real time in order to exploit the flaw. This reduces the risk that this vulnerability can be exploited but does not make it impossible, updating should be a primary remediation focus regardless of the difficulty in leveraging the exploit.

Do I need to regenerate any certificates?

No, this issue does not result in certificate or private key information leaking.

How can I tell if I'm vulnerable to this issue? Is it possible to test remotely for the presence of this issue?

All versions of OpenSSL are vulnerable to this issue. Review the relevant solution for your product:
Red Hat Enterprise Linux
Red Hat Enterprise Virtualization
Red Hat JBoss Middleware
Red Hat Storage

Red Hat Access Labs has released the CCS Injection Detector to you validate your systems have been patched against this vulnerability.

How can I verify the update is working properly?

You can use the Access Labs CCS Injection Detector to verify the update has been applied successfully.

Is there a way to mitigate this issue without an update?

There is no known mitigation for this issue. The only way to fix it is to install updated OpenSSL packages and restart affected services.

Does this issue affect other TLS libraries?

Red Hat has reviewed the NSS and GnuTLS libraries for this issue. We have determined that these libraries are not affected by this specific issue.

Do I need to update my OpenSSL package, even if I am not running version 1.0.1?

Red Hat suggests everyone updates their OpenSSL packages regardless of the version they are using. See above for further details.

Is this issue being exploited in the wild?

At the time the issue was made public, we were not aware of any public exploits for this issue or that it is being exploited in the wild. We believe an exploit could be written for this issue, however exploitation requires the attacker to intercept and alter network traffic in real time.

When did Red Hat find out about this issue?

The OpenSSL team was notified about this issue on May 1, 2014, and contacted Red Hat and other OS distributions on June 2, 2014. This issue was made public on June 5, 2014.

What can an attacker actually do with this issue?

This issue could allow an attacker to conduct a man-in-the-middle attack against a vulnerable OpenSSL client communicating with a vulnerable OpenSSL server. The attacker could then potentially view or modify the secured traffic. The attacker would need a way to access network traffic between the communicating parties and alter it. This OpenSSL issue alone does not provide such level of access to network traffic.

Why do Red Hat's security advisories list multiple CVE IDs?

OpenSSL is fixing several issues with their latest update. Red Hat's updates fix the issues as relevant to our various versions of OpenSSL. This issue has been singled out as the most serious and we are providing additional information.


YOu mention that versions 1.0.1 and higher are impacted. That would mean the newest updated versions are impacted also.
You need to list the minimum version that is NOT impacted.

When will a fix for the vulnerability be available?

The fix is already available, please update to the newest package version.

If you follow the links they do list the specific package versions which are patched and therefore no longer a target. The version 1.0.1 is the OpenSSL version, not the package version.

Are there fixes available for JBoss EAP 6.2.0 or EAP 5.1.0? I noticed the fixes are available only for JBoss EAP 6.2 CP03 and JBoss EAP 5.2 versions and also they provided only for windows and solaris. What about the other versions and other operating systems?

Updates are available for the latest respective version of EAP; earlier versions of EAP are not supported. Users are always encouraged to upgrade to the latest version which provides further security updates, bug fixes, and enhancements.

For instance, for JBoss EAP 6.2.x, 6.2.3 is the latest version and the erratum indicates that it serves as a replacement for earlier versions:

Likewise for JBoss EAP 5.x, 5.2.0 is the latest version and the erratum indicates that it serves as a replacement for earlier versions:

In light of the above, running older JBoss versions exposes a lot more problems than just this as a lot of security updates and bug fixes (that have been fixed in later versions) are not available to the older (unsupported) versions. As a point of reference, 5.2.0 was released in January of 2013, so 5.1.0 is much older than that.

As for packages being released on other platforms, there are only three supported platforms for EAP: Windows, Solaris, and Red Hat Enterprise Linux. The Windows and Solaris platforms received their update yesterday, and users on Red Hat Enterprise Linux would consume the openssl update via the Red Hat Enterprise Linux channels, so there is no need to provide an openssl update for the Red Hat Enterprise Linux version of JBoss.

I hope that answers your questions. If you have further concerns, I would suggest contacting support directly.

why aren't the patched versions available for download yet? You send out an email to fix this issue, but don't even have the openssl-0.9.8e-27.el5_10.3 rpm available for download.

The errata and patched packages are now posted. It's odd that this FAQ does not cite RHEL5 in "Products affected", yet there are errata and packages applicable to RHEL5.

If you are still having trouble downloading the rpms, you may be running into a yum cache issue. You can try "yum clean all && yum update" which will clear the cache and should allow you to download the new packages.

"This can only be exploited if both server and client are vulnerable to this issue" What client applications are we talking about? Anything that uses certificates generated by OpenSSL (putty, filezilla, etc)? Thanks

About openssl098e-0.9.8e-17.el6_2.2.x86_64 available for RHEL6, is new version openssl098e-0.9.8e-18.el6_5.2.x86_64 CVE-2014-0224 bug free?

If you look at the erratum, you will see that this is correct. The erratum lists the packages that contain the fix:

openssl.x86_64 0:1.0.1e-16.el6_5.14


Restarted SSHD, test still fails, also perl script test fails on internal systems that have been patched.

SSHD does not use openssl in a vulnerable way, so restarting sshd would not make a difference. If you want to restart vulnerable services, you can use the "Optional step 2" noted in (yes that article is for Heartbleed, but the instructions for this are the same).


After patching do we need take reboot of the systems.

Trying to address the vulnerability OpenSSL Multiple MITM and DTLS Invalid Fragment Vulnerabilities. At the following page, it for the bug fixed 1103598 CVE-2014-0195 & 1103586 CVE-2014-0224 it shows that versions 1.0.1h are not vulnerable versions and anything below would be considered vulnerable. On this page it shows that version 1.0.1e is the minimum version needed to fix the vulnerability for CVE-2014-0224. Would you be able to clarify which version would satisfy the OpenSSL vulnerability? Thanks.