• December 1, 2017

To show the applicability of ThreatSCOPE as an analysis tool for real-world vulnerabilities we highlight its capabilities by performing a vulnerability-centric reverse engineering of the OpenSSL library. This example captures the connection points, vulnerability points, and related paths involved in the Heartbleed vulnerability recently discovered in OpenSSL. This was a real vulnerability present on nearly all webservers using OpenSSL and allowed for private data to be leaked from those webservers for nearly two years until its discovery.

Figure 1: Connection Point/VPC overview of OpenSSL. Procedures containing connection points are shown in yellow. Procedures containing silent VPCs are shown in blue, those with modifying vulnerabilities are red, and procedures containing both are shown in purple.

We begin our analysis by looking at ThreatSCOPE’s vulnerability-centric view of the entire OpenSSL library, shown in Figure 1. This graph shows a high-level view of the procedures containing connection points in the library and the vulnerability point candidates that can be reached from them. The first thing to notice in this view is the relatively small number of procedures being shown, as compared with over 6,000 procedures in the OpenSSL library. The tool has quickly reduced the scope of the vulnerability assessment to only procedures containing connection points and vulnerability point candidates, as identified through ThreatSCOPE’s program analysis techniques.

The procedures in this view are color coded, enabling an analyst to quickly differentiate between procedures containing connection points (yellow) and silent/modifying vulnerability points (blue procedures contain silent vulnerability points, red procedures contain modifying vulnerability points, and purple procedures contain both). Two lists on the left side of the view enumerate all of the connection points and vulnerability points being shown. To look for vulnerabilities that could allow data to be leaked from the SSL server we notice three procedures containing connection points, named xxx_read_bytes. The names of these procedures imply that they allow the caller to read data from the SSL server. Based on this we choose to investigate these procedures to look for vulnerabilities that could allow data to be leaked from the server.

Figure 2: Vulnerability paths for the ssl3_read_bytes procedure, which contains an output connection point. This view shows vulnerability paths that may allow for data to be leaked from the SSL server via this connection point. In particular, the path between memcpy and ssl3_read_bytes that goes through tls1_process_heartbeat is the actual path that is exploited in the Heartbleed vulnerability.

After clicking on the ssl3_read_bytes procedure in the list, ThreatSCOPE shows the view of vulnerability paths involving this connection point. These paths are shown in Figure 2. This view shows two procedures containing vulnerability points reachable from ssl3_read_bytes. Both procedures are shown in purple, indicating they contain silent vulnerabilities and have the potential to allow for data to be leaked. We also notice there is a path to a vulnerability point candidate in the memcpy procedure which goes through the tls1_process_heartbeat procedure. This is actually the procedure in the OpenSSL library that handles the SSL heartbeat packets that are used to deliver the exploit in the Heartbleed vulnerability.

Figure 3: The contents of the tls1_process_heartbeat procedure, which handles the heartbeat request packet exploited by Heartbleed. This procedure calls memcpy with an unchecked length argument, which originates from the ssl3_read_bytes connection point. When exploited, this vulnerability allows data to be read beyond the end of the intended input buffer, causing data to be leaked from the SSL server.

To look further into the Heartbleed vulnerability we click on the tls1_process_heartbeat procedure to show its contents. This brings up the view shown in Figure 3 in ThreatSCOPE. This view shows the call to the memcpy procedure that is responsible for the Heartbleed vulnerability. The vulnerability results from the fact that the length argument to memcpy is derived from an input received from the ssl3_read_bytes connection point. An attacker is able to control this length argument, causing memcpy to read beyond the end of an SSL record being copied. Since the tls1_process_heartbeat procedure fails to check this length argument this causes the vulnerability point candidate in memcpy to be exploited.

Figure 4: The contents of the memcpy procedure, which contains several silent VPCs. These are the VPCs that are exploited by the Heartbleed vulnerability.

To view the vulnerability point candidates exploited by Heartbleed we can click the memcpy procedure to view its contents. Figure 4 shows two of the silent vulnerability point candidates in memcpy, shown in red. When the Heartbleed vulnerability is exploited, these load instructions are allowed to read beyond the end of the intended input buffer and the leaked data is stored to the output buffer passed to memcpy and ultimately leaked from the SSL server via the connection point.