We are responsible for more than 30,000 user logins on computers which had been susceptible to the Heartbleed bug. As you may imagine, that means we have been watching very carefully for signs of trouble. So far, we have found no evidence of any compromise. What this does not mean is that complacency is acceptable.
Media reports have in some cases flatly stated that this bug allows an attacker to compromise any server with the bug. That is, to gain access to the server at the administrator level. This is almost total nonsense. As you will see from what follows, the problem is entirely limited to data flows. It’s true that if an administrator happened to log in while an attacker was running an exploit, there is a slight chance that his login name and password were captured. On our systems I can say unequivocally that this never happened. We use a two factor encryption system. The second part was exposed to the bug, but the first part was never in jeopardy.
As an aside, this bug has created a much needed uproar in the security community. I checked the online banking system I use. I found that while it was never susceptible to the heartbleed bug, it was susceptible to man in the middle attacks. That is nearly as serious! I suggest you check and complain at any secure sites you need to use. Here is a way to check:
Just put the subject website name in the box.
Very few of our users have followed our advice and changed their passwords. If you are one of them, please do so. It’s true that media reports have been overblown and the probability that your account has been affected is low. None the less, this is NOT something to ignore.
We have more information now about this bug, how it works, what it would take to compromise a server and what it would take to compromise any individual account. It’s not nearly as bad as first reported.
It’s a buffer overflow vulnerability. When a program starts up, it allocates memory to hold what it needs to do its work. In the case of openssl (the program with the bug) as it services requests it allocates and frees memory to temporarily hold the information flowing in and out. When a request has completed, the pointer to this memory is discarded. The problem is that whatever was in that area is still there. The bug allows an attacker to request and get what was left over from the last request which used that memory area.
Memory is allocated on what’s called the heap, from the bottom up. When openssl starts up, the first thing it does is load public and private keys into the heap. This means the private keys are in the lowest part of memory. Following is a diagram of subsequent memory allocations:
The client machine is allowed to check with the server periodically to see if the encrypted connection is still intact. This is called a heartbeat. The client sends the server a test packet and the server sends it back as verification. The bug is that the server fails to sanity check the packet size which is provided in the first few bytes of the request, “length” in the diagram. It returns a memory area as large as whatever the client put there. If it’s bigger than what was sent, material left over from the last request is sent. If that happens to contain something sensitive, we have a serious problem.
Initially it was reported that the attacker could gain access to the keys to the kingdom, the server private encryption keys. Security experts, with an abundance of caution, are unwilling to flatly state that it is impossible for an attacker to get these keys, but that appears to be the case. The keys are located in the lowest portion of memory which is never freed and reused. Using an assortment of scenarios, literally hundreds of millions of attempts have been made to get the keys. None has yet succeeded.
UPDATE: Although the process is difficult, it has now been proven that it was possible to obtain the server keys.
Again, the likelihood that your passwords have been compromised by this particular bug is very low. Our servers were updated and new security certificates issued within 3 hours of the announcement.
However, recent security studies have been done on the source of the bot net (robot network) problem. A bot net is a group of compromised computers being controlled remotely by someone other than the owner. They are used in concert or individually to attack other computers. The studies have provided good evidence that about 37% of computers connected to the Internet with broadband connections are participating in bot net activity. This means there is roughly a 1 in 3 chance that your computer is one of them. If it is, you can bet your passwords are out there. If you have been complacent about security, you really need to check for this.