By Maksym Schipka
Not so long ago I wrote two blog posts on the Heartbleed vulnerability in OpenSSL. In one of them I alluded to the fact that we have not seen the end of it, unfortunately I was right.
So, as promised, six more vulnerabilities have been found in OpenSSL:
- SSL/TLS MITM vulnerability (CVE-2014-0224)
- DTLS recursion flaw (CVE-2014-0221)
- DTLS invalid fragment vulnerability (CVE-2014-0195)
- SSL_MODE_RELEASE_BUFFERS NULL pointer dereference (CVE-2014-0198)
- SSL_MODE_RELEASE_BUFFERS session injection or denial of service (CVE-2010-5298)
- Anonymous ECDH denial of service (CVE-2014-3470)
The most critical of them are CVE-2014-0224, and CVE-2014-0195. The remaining four are denial of service vulnerabilities, the impact of which can be mitigated using the likes of Fail2Ban.
CVE-2014-0195 can lead to remote code execution (i.e. a bad guy running their program on your computer) during encrypted voice or video conversations. This bug has been around for about 4 years, after having been introduced by the author of Heartbleed (I do feel for this guy) without being noticed. So far, Google Talk seems to use OpenSSL and it is unclear to what extent they use DTLS, although according to the source code it is being used. The users of Skype or other Microsoft technologies will not be affected, although further research, with regards to which libraries are used in popular video and voice chat applications, is required.
CVE-2014-0224 is a vulnerability which enables a ‘Man-In-The-Middle’ attack in the case where both the client and server are vulnerable. It has been around for a whopping 15 years. The vulnerability means, for example, should an Apache server be accessed over SSL using a web browser based on OpenSSL (and there’s not too many of these – for example, Lynx/SSL is a modification of command line Linux version of a browser that would be vulnerable, or w3m is Linux-terminal browser) then a person who is able to sniff communications could potentially decipher what is being exchanged. Needless to say, the likelihood of this is almost negligible and the fact that someone is trying to exploit would probably indicate the presence of an ‘Enemy Within’.
Unlike Heartbleed, these two critical vulnerabilities require both the client and the server to be affected. As a result none of them affect non OpenSSL-based browsers (i.e. they don’t affect Internet Explorer, Chrome on the desktop and iOS; Safari or Firefox). In other words, the vast majority of people out there do not need to take any action.
To conclude: despite the fact that these vulnerabilities are by far less critical than those in Heartbleed and the number of affected platforms is a lot smaller, they are all worth patching on the server side to ensure that the cases where the vulnerabilities ‘could’ work are covered.
But, as I wrote in SC Magazine almost 10 years ago (!), if a piece of software is as large or as complex as OpenSSL, it will have vulnerabilities in it regardless of how much effort has been put in place to eliminate them. The open source code was perceived to be less vulnerable due to everyone’s ability to examine and improve it. We are learning now that there is a significant gap between having the ability to check source code and actually checking it for potential security issues.