Heartbleed and its impact on embedded security
Heartbleed, the recently popularized bug in the open source security library OpenSSL, is the worst kind of coding error. This is because not only is the code used all over the structure of the Internet, but also because no one can really understand the extent of the damage. This is why it is likely that Heartbleed will go down in the annals as one of the worst security exploits of the decade.
However, the majority of publications in the last few weeks have focused on the security of consumer’s usernames and passwords. It’s also worth understanding how Heartbleed affects and informs us about security in embedded designs. But first, let’s start at the details of the bug known as Heartbleed and its effect on Internet security.
OpenSSL, TLS, and Encryption
There are many detailed explanations of Heartbleed available on the Internet. But let me briefly summarize:
Heartbleed is a code issue that is part of OpenSSL, a common open source library for doing secure communications using the SSL (secure socket layer) protocol. The newer versions of the SSL protocol go by the name TLS (transport layer security) instead. TLS can be used to add secure communication to a number of Internet services, but use of TLS with web servers is the most common. When used on a web server it creates a secure communication channel denoted by web addresses starting with “https://”.
TLS for web servers provides two key features:
* First, TLS encrypts the communication channel between each web browser and the web server so that the communications cannot be read if intercepted. This protects all the traffic, but specifically protects sensitive information such as the username and password when a user logs in to a website.
* Second, TLS also provides a way to prove and authenticate that the web server in question is the web server that was requested. This is done by the web server proving it possesses secret data (a private key) that corresponds with a publicly available identity (a certificate).
These two features are crucial to secure Internet communication and TLS for web servers. The actual means by which this security is accomplished is via complex math from the field of cryptography.
Details of Heartbleed
The problem with Heartbleed is that it leaks relevant information through a coding bug in the OpenSSL library. This coding bug is sadly simple. A correct length check was not added to the code when a feature was added a couple of years ago.
Figure 1. How the TLS Heartbeat Extension functions in OpenSSL normally.
The feature was from a relatively new specification, known as the TLS Heartbeat Extension (Figure 1 above), specified in RFC 6520. The TLS Heartbeat Extension was added to help keep TLS connections alive, when firewalls and other network devices might decide to time them out. While it is a worthwhile feature, introduction of this feature also introduced a bug.
The outcome from this rather simple coding error is pretty dire. If a special malicious network packet is sent to a server with the Heartbleed code bug, the attacker sending the packet can obtain up to 64kb of memory from the OpenSSL process. This is because the malicious packet causes not only the relevant Heartbeat data to be sent as would happen in the normal case, but also adjacent memory as well (Figure 2 below). Remotely obtaining memory from a web server is always bad as it may contain information that is sensitive. However, this is far worse because the memory in question is located in or near the OpenSSL library, so it is likely to be sensitive.
Figure 2 A malicious packet exploiting the Heartbleed bug, returning memory beyond the Heartbeat payload.
What sensitive information could be nearby? One thing is decrypted communications from other web clients to the web server. This is the most common thing found when using Heartbleed scanning tools. Usernames and passwords can easily also be in the 64kb of memory sent back. Or it could be the contents of the web pages another user on the server has retrieved, which could contain personal information like bank balances or credit card numbers. Either way, data sent encrypted to the web server may be leaked.
Worse yet is the possibility that the 64kb of memory contains the web server’s private key. This short piece of secret data is used mathematically to prove that a web client is talking to the right server. If an attacker is able to get this information they could impersonate the web server. Also, it may be possible to decrypt the historic traffic to the web server with the private key. This would be highly useful for intelligence agencies and others trying to intercept secure communications.
Furthermore, more than 64kb of data can be obtained. 64kb of data can be repeatedly obtained without any discernable log entries. An attacker is likely to run the attack many times and see what can be obtained from the web server’s memory. Most likely, they’ll be able to obtain some usernames and passwords. However, in the last few weeks attackers have also demonstrated the ability to retrieve a private key.
Ultimately, the maddening thing about Heartbleed for the security community – is that we cannot understand how bad the security breaches can be. It’s unclear if anyone exploited the Heartbleed bug because exploiting this leaves no discernable trace. The best case scenario is that no one knew about the code bug and attack until recently.
The worst case scenario is that that many knew about the code problem – and years of Internet traffic have been exposed to nefarious parties. Regardless of what happened, in practice little can be done. The best approach is to patch OpenSSL, change all web server private keys, and recommend that all users change their passwords.
Impact on embedded systems
So far the focus has been on web servers. However, how does this translate to embedded? First, let’s examine how these problems translate to OpenSSL on embedded. And second, let’s investigate some of the underlying causes and how they translate to embedded systems.
First, how are embedded systems with OpenSSL affected? The most pressing question for some is: my firmware contains a version of OpenSSL with the Heartbleed bug (versions 1.0.1 through 1.0.1f). Do I need to release a new firmware image? The answer is yes. If your embedded device is running a server using OpenSSL on the Internet – scanners will eventually find the device. And once found, critical data can be obtained from the device when the Heartbleed bug is exploited.
However, what if the embedded device instead only uses OpenSSL in its client capacity? Is there cause for concern?
Unfortunately, there is trouble with OpenSSL clients as well. There is a more complex attack called Reverse Heartbleed that can attack OpenSSL clients who try to connect to servers. While this attack is harder to accomplish than regular Heartbleed, it’s a good idea to update any firmware that uses OpenSSL for TLS.
These are just some general guidelines, but it may be worth having an audit instead. My company, among others, offer services to review embedded code and investigate what security risks exist in embedded designs.