It sounds like science fiction: 4 missing lines in a computer program compromise at least one quarter of the Internet’s cryptographic infrastructure! The proportion of vulnerable Alexa Top 1 Million HTTPS-enabled websites have been estimated as lying between 24–55% at the time of the so called Heartbleed vulnerability disclosure [10, p. 4]. Another study found “that the heartbeat extension was enabled on 17.5% of SSL sites, accounting for around half a million certificates issued by trusted certificate authorities. These certificates are consequently vulnerable to being spoofed (through private key disclosure), allowing an attacker to impersonate the affected websites without raising any browser warnings [11].”

The Heartbleed vulnerability, listed as CVE-2014-0160, was publicly disclosed on 04/07/2014 with the following statement [12]:

The bug had been introduced with a minor SSL/TLS protocol extension called Heartbeat in January 2012. From the beginning the vulnerability had been widely exploited: For example, the U.S. National Security Agency NSA knew for at least two years about the Heartbleed bug, and regularly used it to gather critical intelligence [13]. As another example, a group of Chinese hackers referred to as “APT18” used Heartbleed to bypass the security systems of the US “Community Health Systems” company and stole 4.5 million patient records [14]. Estimating how widely Heartbleed was and is being exploited is difficult as the attack leaves no trace. The stolen keys are usually stored for later usage in more complex attack scenarios, as Raxis, an independent penetration testing firm, has demonstrated [15].

Even though the Heartbleed patch itself has only a handful of characters, its recovery is tremendously expensive and is far from complete. Not only all keys and certificates on millions of servers have to be renewed, also all secondary key material is affected: for example all user passwords must be considered compromised and therefore have to be replaced. Venafi [16] estimates that in April 2015, one year after the disclosure of Heartbleed, 74% of Global 2000 organisations are still exposed to attacks due to incomplete remediation. This is only 2% less then in August 2014!

Bugs in software come and go, but Heartbleed is unique in many ways: Never has a software bug has left so many private keys and other secrets exposed to the Internet for such a long time so easy to exploit without leaving any trace.

The bug’s name “Heartbleed” derives from Heartbeat a protocol extension to the TLS/DTLS protocol introduced in January 2012 as defined in RFC 6520 [17]. It allows a SSL/TLS client to test if a remote connection is still alive without disturbing the data stream. The client sends an TLS1_HB_REQUEST with a nonce payload string. The server reads this string and echoes it back to the client. The client finally compares its own sent nonce payload string with the received payload string from the sever. If they are equal, the connection is still alive.

The TLS1_HB_REQUEST package sent from the client contains a field called payload in the source code (Table 2, “Vulnerable Heartbeat code in C”) that indicates the length of the payload string. This length is used to determine how many Bytes the server needs to copy in the TLS1_HB_RESPONSE package by executing the memcpy-function in line 6. Figure 2 shows how the server assembles a regular TSL1_HB_RESPONSE package based on the received TSL1_HB_REQUEST package. In order to simplify the graphic, the random padding of 16 Bytes which are systematically appended to both packages is not shown.

The code in Table 2, “Vulnerable Heartbeat code in C” implements mainly two functions: the lines 1, 2 and 6 deserialise the incoming TLS1_HB_REQUEST package and the lines 3 to 7 serialise the outgoing TLS1_HB_REQUEST package.

The so called Heartbleed vulnerability is an implementation problem, i. e. programming mistake in the very popular OpenSSL library [18] resulting from improper input validation due to a missing bounds check. It is important to note that there is no design flaw in the Heartbeat protocol itself.

The programming mistake was introduced with the first version of the Heartbeat feature committed in January 2012. Table 2, “Vulnerable Heartbeat code in C” shows the details of the vulnerable Heartbeat-commit introducing the so called Heartbleed-vulnerability.

Exploiting the Heartbleed-vulnerability is very simple: the attacker sends a TLS1_HB_REQUEST-package with a spoofed payload-length field as shown in Figure 3. Here the payload-length needs to be larger than the actual payload string for example 0xffff. OpenSSL receives the flawed package and deserialises it (cf. lines 1, 2 and 6 in Table 2, “Vulnerable Heartbeat code in C”). Because of a missing validity check the spoofed deserialised payload-length (cf. line2) is passed directly to the memcpy(bp, pl, payload) instruction (line 6) and is there used to determine how many Bytes are to be copied and sent back to the attacker. Thus a Buffer-Overread occurs and discloses 64KiB of internal OpenSSL memory.

From the functional point of view Heartbleed is best classified as a CWE-502: Deserialization of Untrusted Data weakness: “The application deserializes untrusted data without sufficiently verifying that the resulting data will be valid.”

Figure 4 shows how trivially the bug can be fixed. The patch introduces the missing validity check comprising two if statements.

The bugfix as shown in Table 3, “Patched Heartbeat code in C” in detail: The first if statement checks if the incoming TLS1_HB_REQUEST is as least as long as the its minimum required length and the second if statement checks if the payload string is at least a long the payload-length field pretends.

The author of the code who introduced the Heartbleed vulnerability in OpenSSL is Dr. Seggelmann, a programmer who worked on the OpenSSL project during his PhD studies. Interviewed after the incident by the Guardian he said [19]: “I am responsible for the error, because I wrote the code and missed the necessary validation by an oversight. Unfortunately, this mistake also slipped through the review process and therefore made its way into the released version.”

For me there is no doubting the sincerity of this statement. But in view of future similar incidents, it is important to note that Heartbleed is part of a vulnerability class predestined for intentionally introduced weaknesses. As we saw in the previous chapter, Heartbleed can be classified as a “CWE-502: Deserialisation of Untrusted Data” weakness. This kind of vulnerability is listed as potential “CWE-505: Intentional Introduced Weakness” (cf. Figure 5 [20]).

Knowing about the efforts some public authorities undertook in weakening international crypto-standards, the Sydney Morning Herald asked shortly after the disclosure of Heartbleed [21]: “Is this a man who would purposefully leave a gaping hole in the internet, which the US National Security Agency could have been exploiting to spy on people’s communications?”. Dr Seggelman denied this in an interview with Fairfax Media. He said [21]: “It’s tempting to assume that, after the disclosure of the spying activities of the NSA and other agencies, but in this case it was a simple programming error in a new feature, which unfortunately occurred in a security-relevant area.”.

In October 2015, the Dutch government donated €500,000 to the OpenSSL project to enforce Internet encryptions standards [22]. In a public statement, Mr. van der Steur, Holland’s Minister of Security and Justice, said that “his country opposes the idea of backdoors in encryption technologies, considering strong encryption vital for the protection of privacy for citizens, companies, the government, and the entire Dutch economy” [23].

One could interpret this donation as a hint that Heartbleed had been intentionally introduced. But we should not forget that a missing validation is a very common mistake. Furthermore, finding some missing lines of code is always harder than detecting a flaw in code. This is also true for code reviewers. Hence it is not surprising that the vulnerable code passed the review process. In fact, there is no explicit flaw in the vulnerable code: i.e. there are no explicit semantics in C/C++ telling that memcpy(bp, pl, payload) can eventually mean something like: “copy the payload string including all secret private keys and certificates stored in memory”!

In C/C++ many things may happen behind the scenes. This makes the language so elegant. But going back to the 1970s when C was developed: the systems had not yet had to deal with malicious input data. In those days, the main concern in writing computer programs was producing correct results for a small set of valid input data: Do what is written in your program can be well expressed in C/C++ semantics. But the situation has fundamentally changed since. Once connected to the Internet, evil lurks everywhere. Today’s programs have to deal with every imaginable input. This is why we need programming languages that allow us to express: Do only what is explicitly written in your program and do nothing else! - Rust is such a language [24].

The Heartbleed bug would not have been possible if OpenSSL had been implemented in Rust. We have seen that Rust's memory management prevents inter alia Buffer-Over-Read which is the origin of the Heartbleed vulnerability. With Rust no disastrous data leakage could have occurred as it is impossible to read beyond any data structure. Notwithstanding this, attempts to read data out of bounds ends the process by default. This means in a Heartbleed attack scenario the impact would have been limited to a deny of service. From a theoretical point of view the findings are not surprising as they result directly from Rust's core property: memory safety.

In order to keep the Rust code in Table 7, “Patched Heartbeat code in Rust” comparable to the original in C Table 3, “Patched Heartbeat code in C” no optimisations were made. Here are some suggestions for improvement:

Rust's main innovation is the introduction of new semantics defining ownership and borrowing. They translate to the following set of rules which Rust’s type system enforces:

By observing the above rules Rust regulates how resources are shared within different scopes. Memory problems can only occur when a resource is referenced by multiple pointers (aliasing) and when it is mutable at the same time. In contrast to other languages, Rust's semantics allow the type system to ensure at compile time that simultaneous aliasing and mutation can never happen. As the check is performed at compile-time no run-time code is necessary. Furthermore, Rust does not need a garbage collector: when owned data goes out of scope it is immediately destroyed.

A very common group of programming mistakes is related to improper handling of indexes especially in loops, e.g. “CWE-129: Improper Validation of Array Index” (cf. Table 9, “Common weaknesses in C/C++ affecting memory avoidable with iterators”).

In addition to traditional imperative loop control structures, Rust offers efficient iteration with functional style iterators. Like in Haskel iterators are lazy and avoid allocating memory for intermediate structures (you allocate just when you call .collect()).

Besides performance considerations, iterators considerably enhance the robustness and safety of programs. They enable the programmer to formulate loop control structures and to manipulate vectors without indexes! (See example in Table 10, “Vigenère cipher in Rust”).

It must be noted that even with iterators out of bounds-errors may occur. Nevertheless, they should be preferred because they reduce the probability of errors related to indexes drastically.

It is the language design goal Zero-Cost Abstractions that makes the C/C++ language so efficient and suitable for system programming. It means that libraries implementing abstractions, e.g. vectors and strings, must be designed in a way that the compiled binary is as efficient as if the program had been written in Assembly. This is best illustrated with memory layouts: Figure 6 shows a vector in Rust. Its memory layout is very similar is to a vector in C/C++.

Java, also a memory safe language, enforces a uniform internal representation of data. Here a vector has 2 indirections instead of 1 compared to Rust and C/C++ (cf. Figure 7). As the data could be represented in a more efficient way in memory, we see that Java does not prioritise the Zero-Cost-Abstraction goal.

How about other data structures and overall performance? A good estimation is to compare benchmarks of small and simple programs. Too complex programs should be avoided for this purpose because variations of the programmer’s skills may bias the result. According to the “Computer Language Benchmark Game” [25] Rust and C/C++ have similar benchmark results.

As Rust uses the LLVM framework as backend, it is available for most embedded platforms.

The above discussed features are only a small selection of Rust's qualities. Not less important features like threads without data races, minimal runtime and efficient C bindings result together in an ideal tool for secure embedded system programming.