OpenSSL: New Vulnerability: Ability to perform a MITM attack (CVE-2014-0224)

Attack OpenSSL MITM CCS injection

Over the past few years, several serious vulnerabilities have been discovered in various cryptographic libraries. Although only a few of them could actually be massively used before their details became publicly available, and patches were released with corrections, serious vulnerabilities such as Heartbleed prompted developers, researchers and ordinary users to heighten the intensity of these products.

Among the recent bugs fixed in OpenSSL version 1.0.1h, the main one is the possibility of MITM-attack (CVE-2014-0224) against the OpenSSL and TLS protocols.

What is CVE-2014-0224 and should I worry about it?

The short answer is ambiguous, but as in the case of any other vulnerability in security, it is always better to fix than to postpone and worry.
Translator's note : it seems to me that you just need to run and update. This vulnerability is reduced to "no" the whole point of SSL.

To exploit this vulnerability, the following conditions must be met:
')

• Both client and server must be vulnerable. On the client side, all versions of OpenSSL are vulnerable. On the server side, only version 1.0.1 is currently considered vulnerable. If either the client or the server has the vulnerability fixed, exploiting the vulnerability becomes impossible.
  
• The attacker must be a "man in the middle." The attacker must be able to intercept and modify your packets. Ten years ago, such an attack vector seemed almost impossible for anyone other than Internet service providers, since they have access to all network devices through which Internet traffic goes.
  (Translator's note: ten years ago, and unreasonable providers now can listen to neighbor traffic with active sniffers using, for example, arp-poisoning)

However, with the advent of various public wireless access points that are freely available in cafes, restaurants, etc., MITM becomes more real. In addition, there are many software that allows you to create fake access points. Once a client connects to such an access point, an attacker can become a “man in the middle” for the traffic from the client. A successful man-in-the-middle attack can make your credentials, confidential information available to an attacker, or provide an attacker with an opportunity to fake the identity of the victim.

How does this attack work?

The SSL / TLS session is initialized by negotiation through the ClientHello and ServerHello messages with the appropriate party. This part of the protocol is responsible for setting the session attributes, such as the version of the protocol used, the encryption protocol, encryption keys, message authentication code (Message Authentication Code (MAC)), initialization vectors and extensions used.

For various reasons, both the client and server may decide to modify the cryptographic algorithm selection strategies during the negotiation phase (do not confuse with the negotiation protocol). This is achieved using a ChangeCipherSpec (CCS) request. CCS consists of one packet sent from the client and server side to notify that the following data will be protected by new cryptoalgorithms and keys.

In accordance with the standards (RFC 2246, RFC 5246) “CCS is sent during the handshake after the security parameters have been agreed, but before checking that the message“ Finished ”has been sent”. However, in the case of OpenSSL, this is not the case, and it accepts CCS even until the security settings are negotiated. It is expected that when you accept ChangeCipherSpec in the wrong order, there will be out of sync states between both sides. This usually leads to the fact that both parties must break the connection if, however, you do not have other vulnerabilities.

In order to exploit this vulnerability, the "man in the middle" needs:

Wait for the new connection to be established, with subsequent messages from the ClientHello / ServerHello. Send a CCS packet in both directions, which will cause OpenSSL to use a zero-length master key. Session keys will be created, based on this “zero” key and future session keys will also be vulnerable.
Re-initialize matching options.
The attacker is able to decrypt and even modify the transmitted packets.

OpenSSL fixed this vulnerability as follows: CCS packets cannot be received until the master key is installed, and zero-length master keys are not allowed.

How to protect yourself?

Update the OpenSSL package to the latest version provided by your distribution.

Translator's Note:

This vulnerability in OpenSSL was reported by KIKUCHI Masashi (Lepidum Co. Ltd.) on May 1, 2014. Based on his patch, the fix for OpenSSL was developed by Stephen Henson from the OpenSSL team.

Corrected versions released for
OpenSSL 0.9.8 - 0.9.8za
OpenSSL 1.0.0 - 1.0.0m
OpenSSL 1.0.1 - 1.0.1h

Bug in Ghent (corrected version (openssl-1.0.1h) already in portazh)
In trusty, fixed (openssl (1.0.1f-1ubuntu2.2) trusty-security; urgency = medium)
In debian wheezy, there is a fix (1.0.1e-2 + deb7u10). The rest of debian (squeeze, jessie, sid) are currently vulnerable.

Thank you amarao and valdikss for help with the translation.