OpenSSL and Heartbleed
Recently the OpenSSL group released an advisory about a critical bug in the OpenSSL software that could "reveal up to 64k of memory to a connected client or server". This was puzzling at first but it quickly came in to light of how serious an issue this is.
OpenSSL is a framework used for securing a large part of the internet by providing SSL services to a server. This helps secure a connection from peeping eyes online. So obviously a problem with this software can be disastrous from a security standpoint, and this particular problem has proven that. Memory on a server is essentially where everything happens. Keys are stored there, certificates, even user data is stored there while the server is using it. So a bug in security software that can allow up to 64k of that to be revealed undermines the whole point of securing the connection. Further testing from individuals online has shown that the 64k of memory they can get isn't just a one-time deal. They were able to get 64k per request sent to a server. And this isn't a man in the middle attack or anything, this is an attack that can be sent directly to a server.
A quick summary is that a heartbeat request consists of sending data to a server and having that server reply back with the same data. It's used to keep an ssl connection open even though data may not be getting transmitted. The inital heartbeat data sent to the server has a specified size in it for how large the data is. This is where the main problem lies. An attacker could send a 1k piece of data to a server and say it's 64k. The vulnerable implementation of OpenSSL does not verify this size specified. So when the server goes to reply to the heartbeat using the data in memory, it will reply back with 64k of memory from the starting point of the initial saved data. So if only 1k was sent and the server replies back with 64k, that means that 63k of that data was pulled from the memory and could contain almost anything.
While they may only get bits and pieces of server memory, a large amount of requests could be used to start gathering a large amount of data. Furthermore this collection of data is not recorded in logs. This is a major concern with the bug since the listed version that is vulnerable (1.0.1) shows it has been released since March 2012.
There's no way to tell for sure but it's very possible this vulnerability has already been exploited on servers prior to its heads up release to the public. This essentially means that there could be many servers that have had their certificates stolen or user data mined from memory, and there isn't a way to tell who has been effected. A scary part for an end user is that they may not be aware of what servers they communicated with that were vulnerable and there's not really anything a user could have done to prevent an issue like this.
Heartbleed is a big blow to internet security in general given how widely used OpenSSL is. One of the larger providers that was noted as being vulnerable was yahoo.com. With the millions of users they have, that could be a very large leak in user data if anyone attacked with the Heartbleed method. Fortunately most companies, including Yahoo, seem to have reacted very quickly to this incident by changing the software version used or disabling the heartbeat functions altogether until they can permanently fix it. Many providers are also taking steps in getting new certificates issued since it's possible the old ones may have been compromised.
At AppRiver, we don't rely on the OpenSSL library for most of our SSL needs. The few components that did use OpenSSL have been addressed and fixed to avoid any problems. If you run a server and think it may be vulnerable to the Heartbleed attacks or want to check websites you visit, there are places you can check servers at HERE and HERE. If you want to play it safe, it can't hurt to change any passwords at secure sites you frequent as well. This can help you stay safe just in case there are servers out there that have been compromised.