It’s a coding problem, not a security flaw
In this Information Age we are becoming increasingly dependent on the Internet, and we hope that the systems we are using are secure. In most cases the methods put in place are secure, and are open to review from experts around the World. In fact the Internet has allowed standards to be quickly reviewed and for them to become de-facto standards in a way which international standards agencies would never have been able to achieve. Thus we have first class methods, such as the secure socket layer (SSL) which protects the communication of network packets across the Internet. It is SSL which thus protects communications from secure Web sites, such as when we log into our bank account, and you can identify that this is happening when you see the padlock in the browser URL window (Figure 1). These communications use a unique encryption key for every secure connection that we make, and it is almost uncrackable. What we can’t guard against is bad programming practices within the implementation of these protocols, and this is what happened with Heartbleed.
The program which has caused the problem is openssl, which is an open source program which is used to encrypt data, and create secure connections. As cryptography is a challenging area to create programs, often systems will use standard programs which are tested to be working, thus openssl is used by a range of systems. Within on-line systems, openssl is often used to create a secure connection between a user and the Web site. Within this flaw, the versions effected are 1.0.1a to 1.0.1f, and the latest version, released on 4 April 2014, has fixed the flaw (1.0.1g). A system administrator just has to run the openssl command with a version option to determine the version that is running:
billbuchanan@bills-mbp:~$ openssl version OpenSSL 1.0.1f 6 Jan 2014
It’s an implementation problem
The problem was caused because of a programming language called C, where a program has direct access to the memory of a system, and this can be used to leak information or can cause a corruption of the data in the running of the program. This happened with the Whitty Worm in 2004, which was caused by the worm corrupting an area of memory in a running program, which caused it to act incorrectly. With the Heartbleed flaw, the coders allocated an area of memory which related to the size of the payload provided from the other side, thus an intruder could craft a request which then examined the running memory on the Web server that it should not have accessed to. Unfortunately for Heathbleed, this memory area contained stored passwords and private encryption keys (Figure 2).
Why did it happen?
The flaw related to bad coding in the implementation of the openssl coding. While the code has been validated to work with the correct response, what was not checked was when a request was incorrectly formatted. This is a common flaw in many software systems, where a coder checks all the valid input, but forgets that sometimes there are errors in the requests, or where someone maliciously tries to corrupt the requests. Normally a coder will thus test their system against abnormal requests and see how it copes. The program should then catch these problems, and handle them with exceptions. Along with this there is normally a code review, where someone would walk though the code and examine each line for a vulnerability, which again perhaps did not happen. Also, many organisations conduct a penetration test, normally from an external party, who will try and break the code. It is there goal to identify any possible problems, but continually probing for flaws. Again, this seems to have been missed out, possibly because the code is open source, which means that anyone can review the code. Many thus think that open source is more secure, as it is open for review, but perhaps this lead to be lack of due diligence in the roll-out of it.
The difficultly of implementing many of the cryptography methods leads many organisations to adopt well-tried programs, such as openssl. Thus has lead to a wide spread adoption of it for Apache Web servers, which have the large share of the Web server infrastructure across the Internet, currently running at 66%. Many of these will not require secure Web connections, but if they do, they are likely to be vulnerable. As the threats on the Internet increase by the day, it is often difficult for system administrators to keep their systems fully patched, thus there is likely that most systems would not have been patched with the 4 April 2014 update.
The Code in Detail
The flaw was caused by sloppy programming in the C programming language, which has used to create the Openssl program. As seen in Figure 3, the payload received from the client is:
This returns the payload from the user, and returns the number of bytes contained in the payload (payload). After this the program allocates an area of memory with the number of bytes defined within payload:
buffer = OPENSSL_malloc(1+2+payload+padding)
thus the client has defined the size of this, after which an area of memory of the running memory is then copied into it:
memcpy(bp, pl, payload)
which copies the memory and send back in the payload. Thus the client can define a payload of 64KB, and this area of running memory, which can contain usernames, passwords and keys, can be sent back to the client to examine.
What should have happened was that there should have been a check on the payload size from the client, and if it was great than a certain value, nothing should have been returned. The latest version now does that.
Figure 3: Code overview
Nothing has broken with the security infrastructure of the Internet, and we can feel fairly safe in the methods that are used to secure us. What we can’t guard against is poor implementations, and this is the problem caused by Heartbleed, and what is even more surprising was that it went through various versions, before it was released as a Zero Day threat. It is well known that many experts on the Internet know of Zero Day threats long before they are actually released, and we must worry about the leakage of information that happened before the information was released. One major threat, and it is generally one of the major threats on the Internet, is for private keys for organisations to be released into the wild. With this, we could not trust anything which an organisation digital signs, such as access to a secure Web site. There is, though, a revocation process, if an organisation looses its secret key, but the implementation of this is often weak. So, it is hoped that not too many of these keys have been leaked, otherwise we could all be in danger.
Last piece of advice … don’t change your password on a system which does not have the vulnerability or on an unpatched system!
Crawling under a rock
So for a pretty dull little program, which likes to do some maths on data, it has found itself under the spotlight. It shows, though, how shaky our software infrastructure actually is, and how important it is for organisations to test their software, not only for valid data, but for exception points. Having it in open source is also no guarantee that coders will detect problems, in fact, there’s a financial motivation for Zero Day threats not be published, in the same way that mankind have kept secrets about their adversaries. Unfortunately, on the Internet, the skills required to gain this information has significantly reduced against the budgets which were reserved by governments for their intelligence gathering. The Internet often struggles to keep things secret, and even a whisper can become a blast, which resonates, with people racing to understand and probe. Within one day, we had the Python script ready for investigate the vulnerability, where even the most basic computer user could actually gain access to the information exposed from the vulnerability. Welcome to our Brave New World!
If you’re interested on what the shy little openssl program does, you can try a few things at:
and if you like salt, you can try: