There is a new, remotely exploitable vulnerability in OpenSSL that could enable an attacker to intercept and decrypt traffic between vulnerable clients and servers. The flaw affects all versions of the OpenSSL client and versions 1.0.1 and 1.0.2-beta1 of the server software.
The new vulnerability could only be exploited to decrypt traffic between a vulnerable client and a vulnerable server, and the attacker would need to have a man-in-the-middle position on a network in order to do so. That’s not an insignificant set of conditions that must be present for a successful attack, but in the current environment, where open wireless networks are everywhere and many users connect to them without a second thought, gaining a MITM position is not an insurmountable hurdle.
Researchers who have looked at the vulnerable piece of code say that it appears to have existed, nearly unchanged, in the OpenSSL source since 1998.
“The code changes are around the rejection of ChangeCipherSpec messages, which are messages sent during the TLS handshake that mark the change from unencrypted to encrypted traffic. These messages aren’t part of the handshake protocol itself and aren’t linked into the handshake state machine in OpenSSL. Rather there’s a check in the code that they are only received when a new cipher is ready to be used,” Adam Langley, a researcher on the security team at Google, wrote in an analysis of the vulnerability.
“However, that check (for s->s3->tmp.new_cipher in s3_pkt.c) seems reasonable, but new_cipher is actually set as soon as the cipher for the connection has been decided (i.e. once the ServerHello message has been sent/received), not when the cipher is actually ready! It looks like this is the problem that’s getting fixed in this release.”
Masashi Kikuchi, the Japanese researcher who discovered the vulnerability, confirmed that the bug had been present in OpenSSL since the first version and that it likely should have been found sooner.
“The biggest reason why the bug hasn’t been found for over 16 years is that code reviews were insufficient, especially from experts who had experiences with TLS/SSL implementation. If the reviewers had enough experiences, they should have been verified OpenSSL code in the same way they do their own code. They could have detected the problem,” Kikuchi said in his explanation of the vulnerability and how he discovered it.
“Fuzzing may have worked. However, as the history (see below) shows, knowledge of TLS/SSL implementation seems vital.”
The new CVE-2014-0224 bug surfaced two months after the OpenSSL Heartbleed vulnerability came to light. That flaw was considered more serious and affected a huge number of diverse systems and clients and administrators and security engineers scrambled to fix it before attackers began taking advantage of it. Heartbleed caused a lot of discussion and debate in the security community and even bled over into the mainstream, albeit not necessarily with the most accurate details.
This OpenSSL flaw is serious, as well, but likely won’t cause the same sort of distress. Still, Langley said in his analysis that the vulnerability could have a variety of effects.
“The implications of this are pretty complex. For a client there’s an additional check in the code that requires that a CCS message appear before the Finished and after the master secret has been generated. An attacker can still inject an early CCS too and the keys will be calculated with an empty master secret. Those keys will be latched – another CCS won’t cause them to be recalculated. However, when sending the second CCS that the client code requires, the Finished hash is recalculated with the correct master secret. This means that the attacker can’t fabricate an acceptable Finished hash. This stops the obvious, generic impersonation attack against the client,” Langley wrote.
“For a server, there’s no such check and it appears to be possible to send an early CCS message and then fabricate the Finished hash because it’s based on an empty master secret. However, that doesn’t obviously gain an attacker anything.”
The vulnerability affects some mobile implementations of OpenSSL, as well. Google has already released an updated version of Chrome for Android to fix this issue in the mobile version of the browser.
In addition to the MITM vulnerability, OpenSSL fixed several other flaws in its latest release. Four of those vulnerabilities can be used to cause a denial-of-service, while the remaining one can allow remote code execution.
