What we know so far about Heartbleed is that a memory-handling bug in the Heartbeat Extension of the Transport Layer Security (TLS) protocol caused a vulnerability in the “secure” communications path between clients and servers (think the timeout warnings you receive in online banking sessions). Essentially, this resulted in what Todd Ouska, Chief Technology Officer at wolfSSL in Edmonds, Washington (www.yassl.com) calls a “sneaky” reveal of servers’ memory that could expose critical pieces of information.

“The Heartbeat Extension allows a client to tell the server that ‘hey, I’m still here,’ just to tell the peer that you’re still around and don’t close down yet,” Ouska says. “Basically the client sends some data to the server and the server echoes back to let the peer know that it’s still there. This usually requires 1 byte of information.

“Heartbleed is sneaky because when the client sends its 1 byte of information, the echo back from the server [could be] 64 kilobytes of RAM information that can include recently accessed code, keys, and so on,” he continues. “The people that found the bug said they were even able to find passwords and the server’s secret key. It’s basically allowing access to server memory, so anything that the servers accessed recently is vulnerable.”

Though wolfSSL products are based off of original code and do not use OpenSSL as a baseline, Ouska notes that the vulnerability was patched as soon as OpenSSL was informed, and that web servers running vulnerable versions should move to higher versions or at least recompile with the Heartbeat Extension turned off. He also suggested referencing the Heartbleed Common Vulnerabilities and Exposure (CVE) entry, CVE-2014-0160.

How Heartbleed happened
Though it’s difficult to speculate how Heartbleed made it through the OpenSSL approval process and went undetected for more than two years, Ouska cites difficulties working with the C programming language prevalent in server-class and embedded systems as a possible explanation for how the buggy code was inserted.

“It’s impossible to always get it perfectly right,” Ouska explains. “The [Heartbleed] bug is specific to a [programming] platform. It’s somewhat inherent in the C programming language in that it’s easy to shoot yourself in the foot. C is highly prevalent in the embedded space and server space, and I wouldn’t say it’s easy to work with.

“Higher level languages don’t give you access to memory in the same way,” he continues. “C has something called pointers that allow you to have access to RAM. Something like this bug would forget to check RAM and gives the opportunity for memory to be leaked.”

C is commonly used in embedded applications because of its flexibility and small memory footprint, which are baseline requirements for many low-power, deterministic systems. While higher level languages can protect you from code errors like that of Heartbleed, they do so at the cost of performance and power.

To protect against these errors, wolfSSL employs peer review, auditing, thorough testing, and reuse when coding their CyaSSL and other Secure Sockets Layer (SSL) libraries, as well as both static and dynamic analysis tools, Ouska says. A foundation of best practices is the safest “way to get it perfectly right.”