4

My understanding of the Heartbleed vulnerability is that there is no bounds check on the payload length/buffer size so the server can read into memory outside of its process space.

But can the start address be modified?

If not, then the probability of snagging anything interesting from a server with gigs of RAM, where much of the time that space may not change, is far less likely than if any 64K space can be read.

This article seems to sensationalize the impact from a rational discussion of probability to a stance of "you cannot trust anything; your server RAM has been 100% exposed for years".

https://www.schneier.com/blog/archives/2014/04/heartbleed.html

Granted, 64K is a fairly large chunk, enough to store 3,200 SHA1 hashes, but on a 4Gb server, its still only 1 / 67,108th of the total address space - is the threat being hyped?

JdeBP
  • 681
  • 4
  • 13
Luke Puplett
  • 533
  • 1
  • 4
  • 9
  • 3
    I believe it only leaks memory belonging to the process that loaded the OpenSSL library, which concentrates it on a subset that is far more likely to have interesting data. – William Lawn Stewart Apr 10 '14 at 11:06

3 Answers3

12

The 64k block that gets returned is selected effectively at random, which seems like it would make it hard to find worthwhile data. However, there are two factors that significantly increase the threat:

First, the attack won't return memory that was allocated during program start-up. This means the area occupied by boring things like program code won't show up in attack results; likewise, the half of the address space reserved for the operating system won't be returned.

Second, because of how memory allocation is done, the 64k block will tend to come from recently-used memory. For example, if a server handles a lot of login attempts, the memory is likely to have been used for a recent login, and could very well contain a username/password pair or two. Good timing might get you memory used to set up the SSL connection, and you might be able to find an SSL private key in that.

A third point is that the attack can be performed quickly and repeatedly -- and is almost impossible to detect. A home internet connection might be able to hit a server with tens of thousands of heartbeat requests per second.

Mark
  • 34,513
  • 9
  • 86
  • 135
5

The Heartbleed bug indeed allows other parties to read memory outside the intended space, but it does not allow you to read memory from other processes. The start address cannot be modified either by the attacker, it really depends on the memory allocation algorithm which memory ends up to be returned. Most likely this is memory of a recent HTTP request (for webservers and webbrowsers). For busy webservers, there is a high chance of getting completely different data back because the memory was overwritten while serving other users.

Cloudflare investigated the possibility of getting a private SSL key out of the nginx webserver, but found it highly unlikely to squeeze the private key out. The main argument is that the nginx webserver loads the private key very early during startup. Not much memory is allocated/used at that time, so the private key is stored at a low address. When new requests come in, more distant addresses are used, so they think it is hard (and likely impossible) to get the key. That's why they have put up a challenge that ask testers to prove otherwise.

Note that there is no really hard proof that it is not possible to get keys. The paranoid (and safe) stance is then to assume that it is possible (even if the chance of getting hit by a meteorite is higher). To prove that it is not possible to get keys using this single bug, one should check carefully how the memory allocater works and how other external factors may affect the addressing.

The researchers were able to get the private key in "lab conditions". What were these conditions? If they run a custom webserver using OpenSSL on an low-memory embedded device, then this may indeed make it much easier to get the private key, but it is not realistic.

Regardless of whether private keys can be leaked or not, it has been shown that recent HTTP requests and responses can be read from memory. This includes passwords (see Yahoo, I know someone who got 3k passwords in a short time), business documents, source code (including database credentials), login tokens, session IDs and more. Although the main private key was not stolen, it is still quite possible that the premaster secrets were leaked which would allow someone who sniffed the network to decrypt the encrypted data.

As for auditing, you cannot see in webservers' access logs that it had been attacked with this bug. Only with a packet capture, you can tell.

Since attacks are quite stealthy and the bug allows remote attackers to easily gather data that is normally not accessible to the outside (source code) or should be encrypted (passwords), in my opinion Heartbleed is pretty severe. It did get much media press, but that seems to be justified.

Lekensteyn
  • 5,958
  • 5
  • 38
  • 62
  • 4
    So far two people have been able to extract private SSL keys from Cloudflare's test server. https://www.cloudflarechallenge.com/heartbleed – Andy Lester Apr 12 '14 at 06:29
  • @AndyLester Well that seems to be a proof that it is possible to gain keys, and it took less than a day :/ – Lekensteyn Apr 12 '14 at 07:59
  • I like this answer. It discusses the theoretical and empirical and refers to external investigations. – Luke Puplett Apr 14 '14 at 09:51
0

There was an answer here that has since been deleted that was really interesting, at least in the comments it provoked.

Essentially, the answererer was (not very clearly) trying to say that each new allocation of buffer to read the heartbeat from changes the start address, and because you are able to run the attack many times, you are able to randomly pull data from a particular area of RAM, hitting a different spot each time.

Mark says in his answer above:

The 64k block that gets returned is selected effectively at random

He is also presumably alluding to this mechanism.

Luke Puplett
  • 533
  • 1
  • 4
  • 9