Did A Faulty Memory Feature Lead To Heartbleed?

Debate arises over an older memory allocation feature in OpenSSL, and the OpenBSD community starts to tear down and revise the crypto software for its own use.

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 OpenSSLs 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.
OpenSSLs Ben Laurie says he plans to disable the memory feature that de Raadt highlights, but he argues that its still not clear whether the feature caused Heartbleed. OpenSSL, which patched the read-overrun bug in its implementation of the Transport Layer Security protocols 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 hes not convinced that the use of OpenSSLs 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 Raadts 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 OpenSSLs 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 its unfair to say you shouldnt have made that decision years ago.
The key is to keep memory-leakage bugs in mind in software, he says. Take
Akamais 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 didnt get the implementation completely correct. That shows how difficult this is.
[Heartbleed also affects internal servers, clients, and VPN networks. See
Heartbleeds 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, thats 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.

Last News
▸ Some DLP Products Vulnerable to Security Holes ◂ Discovered: 23/12/2024 Category: security	▸ Scan suggests Heartbleed patches may not have been successful. ◂ Discovered: 23/12/2024 Category: security	▸ IoT Devices on Average Have 25 Vulnerabilities ◂ Discovered: 23/12/2024 Category: security

**Cyber Security Categories**
Google Dorks Database	Exploits Vulnerability	Exploit Shellcodes

CVE List

Tools/Apps