Sloppy coding blamed for worldwide SSL 'Heartbleed' vulnerability
"A mistake in C code" is responsible for one of the most serious bugs discovered in any implementation of SSL/TLS encryption: the OpenSSL open source toolkit, according to security engineers with Finland-based Codenomicon, in an e-mail to FierceEnterpriseCommunications Wednesday morning. More to the point, it's a programming shortcut deeply embedded in OpenSSL's C source code, which may be attributed to sloppy coding, but which history also indicates may be an omission intended to make code run faster.
"True, C as a language is infamous for buffer overflows and other memory handling mistakes," says Codenomicon spokesperson Ari Takanen, "but there are reasons why C will still be used especially in operating systems and embedded devices for quite some time. Open SSL is an open-source library commonly used in all types of communications software. Good programming practices can help a long way, but people always make mistakes. That is why testing is still always needed."
Here's a real-world analogy for the situation: Imagine a pay telescope installed on the balcony of a public sightseeing hotspot. If there were no guard posts keeping the telescope from turning 360 degrees, someone could use that telescope to peek into private property. The same principle applies to unmanaged software code: If the matter of public and private boundaries for memory contents is left up to the programmer, then even if the programmer obeys her own rules, someone else using the same code might not.
Only in recent months have Codenomicon engineers Matti Kamunen, Antii Karjalainen and Riku Hietamäki been deploying a tool they call Defensics to check for bugs in commonly deployed security tools. OpenSSL is indeed quite common, responsible for more than 17 percent of the world's site-signing certificates, according to two independent estimates by Netcraft and Datanyze (their numbers differ by a tenth of a percent). Though two-thirds of the world's Web servers run either Apache or nginx servers known to employ OpenSSL, it's a much safer estimate that about 7 sites out of every 40 may be susceptible to having their keys exposed, and later to be spoofed in man-in-the-middle attacks.
Takanen told FierceEnterpriseCommunications that the Codenomicon team discovered "Heartbleed" while working with Google Security's Neel Mehta to improve a feature of their Defensics suite, called SafeGuard. When the feature was introduced last January, the company touted it as using automated analysis to reveal unusual or unexpected responses from software that are more subtle than outright crashes.
In this case, SafeGuard spotted unexpected responses from the "heartbeats" generated by relatively recent versions of OpenSSL. A "heartbeat" is a signal, sometimes generated at designated intervals, that a service uses on an asynchronous and unreliable transport mechanism (such as TCP/IP) to reassure a client service that it's still present.
The Heartbeat Extension protocol was finalized by IETF in January 2011. It's a mechanism for one party in a secure connection to ping the other (once their handshake process is complete), and receive an immediate response. It is an unsophisticated protocol, without so much as a regular rhythm. It simply resolves the problem of assuring both parties in a secure channel that they don't need to renegotiate the terms of their session.
Apparently, OpenSSL versions 1.0.1 through 1.0.1f were originally written in C, but were compiled in such a way as to exclude the type of bounds checking that restricts memory pointers to secure ranges. Since it's not managed code, the C language effectively permits programmers to keep track of their own arrays--a practice that leads to buffer overruns.
It could be sloppy programming. Or it could be an intentionally deployed wrapper (substitute code which adds or perhaps subtracts functionality) that handles the caching of memory differently. Last Tuesday, OpenBSD founder Theo de Raadt noted evidence of the existence of such a wrapper in OpenSSL code, from the comment lines appearing in a description for a macro command. These source code comments read in part: "On some platforms, malloc() performance is bad enough that you can't just free() and malloc() buffers all the time, so we need to use freelists from unused buffers."
Translated, the developer is saying that the native performance of the memory allocation function malloc() and the allocated memory release function free()--both part of the standard C library libc--is so slow, that the only alternative is to create a pointer to a list of amalgamated clusters of memory--a freelist.
In a post to his OpenBSD mailing list Tuesday, de Raadt condemned this type of wrapper, as something he called an "exploit mitigation countermeasure." Specifically, rather than use code designed to crash in the event of possible exploit ("then the bug can be analyzed, and fixed forever"), de Raadt says OpenSSL developers chose to implement a riskier alternative in hopes of reducing crashes and speeding up performance.
That alternative effectively enables the contents of the heartbeat packet to reveal any 64 KB piece of the server's memory. Though that's not a lot in itself, simply repositioning the bounds and pinging again enables a scan of potentially everything, including the keys used to encrypt the current secure session. With those keys in hand, a malicious actor can easily spoof that server.
Despite the fact that Defensics SafeGuard revealed the existence of this latent bug, in his e-mail to us, Codenomicon's Ari Takanen said there's no absolute way for Web servers to determine whether or not they've been compromised. For that reason, they should have their current certificates reissued, and existing ones revoked.
Would this mass reissuance of certificates--in addition to Web servers patching their faulty OpenSSL implementations to version 1.0.1g--impact end users and their client systems in any way?
"If done correctly," responded Takanen, "it should not cause any extra actions to everyday users. If, due to the urgency of the topic, some service providers issue self-signed certificates, then temporarily this can show to users. Those users who wish to check if the certificates have been updated can find the issue from behind the lock icon in their browser."
- read the full story on the Heartbleed bug from Codenomicon