I know about the basic Heartbleed vulnerability and it's consequences and cause. However, I recently read that Heartbleed may cause a server to crash. I am wondering if this statement is true and if so, why is that so.

As far as I understand Heartbleed simply sends back the length the client requested and misses to check if this length is actually true. So I don't see really how it could be possible to crash the server by reading data?


The answer to this question involves a bit of background in how paging works. In modern operating systems applications do not access physical memory addresses but rather virtual memory addresses. The mapping between virtual and physical memory happens in chunks called pages. The page size depends on the hardware, the most common side is 4KB.

When a process is started most of the virtual memory address space is empty. Accessing it will cause a trap into the OS kernel, which may terminate the process and perhaps log the event.

As the process needs memory, it requests memory from the operating system one or more pages at a time.

The heartbleed bug would allow leaking up to 64KB of data. That means it can cross as much as 16 page boundaries (in other words it may span 17 pages). The first of those pages is where the legitimate data is stored, so that page is guaranteed to exist. But the following 16 pages of virtual address space may not have been allocated yet. If that happens there won't be 64KB of data to return, and the OS kernel will have to handle the situation. If no recovery mechanism has been defined, the process will be killed.

Depending on the design of the server software, it may recover from this automatically by simply spawning a new process. I think Apache would spawn a new process. Other software may not automatically respawn. In that case heartbleed could cause the server software to crash and stay down.

A complete crash of the operating system is not possible due to heartbleed. It would require a different bug to crash the operating system.

  • Thanks, I got it. However, if Apache is respawning I guess this should show up in the log or somewhere (even more so if it does not recover)? But isn't one of the problems of Heartbeet also that you can't detect if your server was compromised? Assuming that a real world attack to get useful information would require quite a number of requests, isn't it also quite likely there would be such a crash? – dirkk Apr 27 '14 at 21:01
  • The exact probability of a crash depends a lot on the behavior of the memory management layer in the application. Most applications use a standard library for this purpose, however I read that openssl use their own memory management layer. Some people think the specific memory management layer that openssl uses made the problem worse. – kasperd Apr 27 '14 at 21:49
  • @dirkk I tried sending a SEGV signal to an Apache process from the command line to find out what Apache would log in that case. I tested this on an Ubuntu system and got this message in the error_log: [Sun Apr 27 23:47:47 2014] [notice] child pid 8163 exit signal Segmentation fault (11), possible coredump in /etc/apache2 I believe you would see a similar log message, if heartbleed happened to cause a crash. – kasperd Apr 27 '14 at 21:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.