Vulnerabilities

New MitM Vulnerability Plagues Client, Server Versions of OpenSSL

OpenSSL has been updated to address several security issues, including a flaw that appears to have existed in the code for more than 15 years.

<p class="MsoNormal" style="text-align: center;"><span><span><strong>OpenSSL has been updated to address several security issues, including a flaw that appears to have existed in the code for more than 15 years.</strong></span></span></p>

OpenSSL has been updated to address several security issues, including a flaw that appears to have existed in the code for more than 15 years.

While the infamous Heartbleed vulnerability in OpenSSL might have been patched by most organizations, it doesn’t mean there are not other security holes that plague the popular open source encryption software. On Thursday, the OpenSSL Project announced the availability of versions 0.9.8za, 1.0.0m and 1.0.1h to address a total of seven security flaws.

The most critical of the new batch of bugs is a ChangeCipherSpec (CCS) injection vulnerability that can be exploited through a Man-in-the-Middle (MitM) attack in which traffic can be decrypted or modified.

“The attack can only be performed between a vulnerable client and server. OpenSSL clients are vulnerable in all versions of OpenSSL. Servers are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Users of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution,” the OpenSSL Project noted in its advisory.

The vulnerability, CVE-2014-0224, was reported on May 1, 2014 by Masashi Kikuchi of Lepidum, who discovered it while testing TLS/SSL implementations.

During a handshake between a client and a server, messages must be exchanged in a certain order. In the case of OpenSSL, the timing is good when CCS messages are sent; the problem is that “it accepts CCS at other timings when receiving,” the researcher explained in a blog post.

Masashi believes that the vulnerability remained undetected for so long due to insufficient code reviews. The researcher highlighted the fact that there had been at least two occasions, in 2004 and 2009, when this bug could have been spotted.

Adam Langley, the Google security expert who helped close the Heartbleed bug, has also analyzed the vulnerability and has confirmed that the affected piece of code appears to be unmodified since version 0.9.1c, launched in December 28, 1998.

“The newly disclosed Man-in-the-middle vulnerability in OpenSSL affects all client applications and devices that run OpenSSL when communicating to vulnerable servers of specific versions, but includes the most recent,” Nicholas J. Percoco, VP of strategic services at Rapid7, told SecurityWeek. “This likely contains the majority of systems on the Internet, given that most rushed to upgrade OpenSSL after the Heartbleed disclosure in early April of this year.” 

Advertisement. Scroll to continue reading.

“A Man-in-the-middle attack is dangerous because it can allow an attacker to intercept data that was presumed to be encrypted between a client (eg. an end user) and a server (eg. the online bank, etc.),” Percoco added. “This attack is also passive in nature and will may not be detected by a client, server or network based security controls.”

“This will not be as wide spread as Heartbleed since it requires two points to be broken and it’s a much more complicated attack,” Jonathan Sander, Strategy & Research Officer for STEALTHbits Technologies, told SecurityWeek. “But this should serve as more evidence that organization need to take deep security audits seriously so they know how they are being protected – or not being protected – by the technology they have in place.”

 “Unsurprisingly, security researchers started poring over the OpenSSL source code after the Heartbleed vulnerability,” Jean Taggart, Security Researcher at Malwarebytes, told SecurityWeek in an emailed statement. “We shouldn’t be surprised that there are more flaws in the OpenSSL cryptographic library. Most notable is that the flaws discovered again do not affect the cryptographic methods used, but their implementation.”

In addition to this vulnerability, several other flaws have been addressed in the latest versions of OpenSSL:

CVE-2014-0221: DTLS recursion issue that could lead to a DoS attack, reported by Imre Rad of Search-Lab on May 9, 2014;

CVE-2014-0195: DTLS invalid fragment vulnerability potentially exploitable to run arbitrary code on a vulnerable client or server, reported by Jüri Aedla on April 23, 2014;

CVE-2014-0198: bug in the do_ssl3_write function that allows remote attackers to cause a DoS via a NULL pointer dereference. It affects only OpenSSL 1.0.0 and 1.0.1 where SSL_MODE_RELEASE_BUFFERS is enabled;

CVE-2010-5298: race condition in the ssl3_read_bytes function that can be exploited by remote attackers to inject data across sessions or cause a DoS. Only multithreaded applications using OpenSSL 1.0.0 and 1.0.1 with SSL_MODE_RELEASE_BUFFERS enabled are affected;

CVE-2014-3470: ECDH DoS issue reported on May 28, 2014 by Felix Gröbert and Ivan Fratrić at Google;

CVE-2014-0076: vulnerability previously fixed with the release of OpenSSL version 1.0.1g; it has now also been addressed in OpenSSL 1.0.0m and OpenSSL 0.9.8za.

As HP’s Brian Gorenc pointed out in a blog post, developer Robin Seggelmann is responsible for introducing CVE-2014-0195 into the OpenSSL code base, according to the commit logs.

“Yes, Robin Seggelmann is also responsible for introducing the Heartbleed vulnerability,” Gorenc wrote. “Two big vulnerabilities introduced by the same developer. Seggelmann is not completely to blame, of course. OpenSSL is an open source project. The ‘many eyes’ that look at this code failed to catch this bug, but a new breed of individuals are looking at this code…especially at Seggelmann’s code. This code is now known for having vulnerabilities. There is blood in the water.”

“It’s often said that security is a process, not a product,” Taggart added. “The independent code review, subsequent bug discovery and patching process is the strength of open source.”

*Updated with additional commentary.

Related Content

Copyright © 2024 SecurityWeek ®, a Wired Business Media Publication. All Rights Reserved.

Exit mobile version