Did A Faulty Memory Feature Lead To Heartbleed?

As the dust begins to settle on the Heartbleed bug, developers in the open source community are digging deeper into what really went wrong in OpenSSL to cause the encryption software to be exposed to leaking information and digital keys. One theory: A memory management feature created for OpenSSL left the software open to leaking sensitive data.

Heartbleed and its resulting heartache for the Internet could have been avoided altogether if the OpenSSL software had employed more modern memory management techniques, according to OpenBSD founder Theo de Raadt. An older memory management method used in OpenSSL for optimizing performance called ""freelist" basically keeps the contents of memory "around forever" and exacerbates problems such as Heartbleed.

"Heartbleed would not have worked at all if the [memory] allocator" had fully sanitized the memory, as other software programs do, de Raadt maintains. And OpenSSL's patch fixes only the programming error that led to Heartbleed; there still could be hundreds of security bugs in OpenSSL that have yet to be discovered.

OpenSSL's Ben Laurie says he plans to disable the memory feature that de Raadt highlights, but he argues that it's still not clear whether the feature caused Heartbleed. OpenSSL, which patched the read-overrun bug in its implementation of the Transport Layer Security protocol's Heartbeat extension, has attributed the bug to an implementation flaw in the software.

"Whilst I agree with Theo that the feature should not be enabled by default, as far as I can tell it made no difference whatsoever in the Heartbleed case," Laurie said in an email interview last night about the memory allocation method. Laurie plans to disable or remove the feature altogether. It is used "quite rarely" and was not used in Heartbleed.

However, disabling this feature could trigger another bug, according to Laurie, who is investigating that. "It does appear that under some rather specific circumstances, there is a bug when it is disabled, which will also have to be fixed."

There are at least two memory allocators in OpenSSL, he says, and the "malloc" feature favored by de Raadt and others in the open source community is almost always used by OpenSSL for memory allocation.

Laurie says he's not convinced that the use of OpenSSL's own memory allocator actually led to Heartbleed, but he has not yet been able to conduct a full investigation. "I am fairly sure... that the use of this allocator, whilst perhaps inadvisable, did not reveal any interesting information in the case of Heartbleed," he said in the email interview. "As far as I can see, all that can be leaked by the allocator is data that is sent over the network -- that is, for the most part, encrypted data. That is, data that could be sniffed off the wire -- and hence is supposed not to be useful to an attacker."

Meanwhile, de Raadt's OpenBSD group is busily hacking away at fixes for OpenSSL, all in the name of improving its security in the wake of Heartbleed. OpenBSD plans to remove old legacy code and "risky code practices" without affecting applications that use OpenSSL, de Raadt says.

He maintains that OpenSSL's memory allocator is vulnerable to attack. "Some private information must remain in memory because it will be reused by the software. But other temporary objects which should be discarded remain. Furthermore, the objects are in very predictable places. A number of modern attack methods can use this."

The Heartbleed bug has multiple components, he says. "The primary problem is the ability to access the wrong memory. The secondary problem is that the wrong memory happened to contain security sensitive information. In a more perfect world, that sensitive information would be out of reach, hiding somewhere better."

Chris Eng, vice president of research at Veracode, says hindsight is 20/20. "The decision [about memory allocation in OpenSSL] was probably made for a good reason at the time," he says. "It was probably for performance, not security reasons."

"This may have implications if they find more bugs of this type... the fact that [the] use of this memory allocation might make the impact of the bug greater," he says. "But it's unfair to say you shouldn't have made that decision" years ago.

The key is to keep memory-leakage bugs in mind in software, he says. Take Akamai's failed patch for OpenSSL. "Akamai tried to... set up a separate memory area for secret" data. "The general idea of a separate area was good. They didn't get the implementation completely correct. That shows how difficult" this is.

[Heartbleed also affects internal servers, clients, and VPN networks. See Heartbleed's Intranet & VPN Connection].

Barrett Lyon, founder and CEO of Defense.net, who has been following the online discussions about the OpenSSL memory allocation issue by OpenBSD, says that, if indeed the memory management feature sacrifices security for performance, that's a problem.

"OpenSSL as a project has been very good," Lyon says. But "it was a pretty fatal design mistake" to employ a memory allocation method that risks security.