Application: Find Vulnerability

Detecting sophisticated AC or SC vulnerabilities is like searching for a needle in haystack without knowing what the needle looks like. These sophisticated vulnerabilities are one-of-a- kind. A fully automated approach to detect these vulnerabilities is not possible. Detecting AC and SC vulnerabilities often require domain-specific knowledge [25,42]. The detection

requires exploring software to identify vulnerable code, conceiving plausible attack hypotheses, and gathering evidence by analyzing software to prove or refute each hypothesis. EFG-based program comprehension is important to support such detection.

This section motivates and illustrates the need for the EFG to detect SC vulnerabilities in software. The EFG helps the analyst to focus on the space and time changing events and their governing conditions. If executing such events causes observable space/time differences then it creates the possibility of a SC vulnerability. The governing conditions need to be user- input controlled for an attacker to force the execution of paths with observable space/time differences. Thus, to detect SC vulnerabilities, the analyst must understand the program to answer specific questions: (a) What are the space/time changing events present in the app? (b) What are the governing conditions controlling the execution of these events? (c) Can the governing conditions be controlled by user inputs? We propose a three-phase approach for this application.

This application involves several complex program comprehension problems. We show that the EFG is useful when the analyst has to gather evidence to prove or refute an SC attack scenario.

Phase I:Automated Exploration. The objective is to precompute information that serves as the basis for the analyst to begin the investigation. The precomputed information includes the locations of space/time changing loops and the user-input controlled conditions.

Phase II:Hypothesis Formulation. After reviewing the precomputed information, the analyst hypothesizes possibilities for SC attacks. By the end of Phase II, the analyst has hypotheses that need to be either validated or refuted.

Phase III:Validating the Hypotheses. The objective is: (1) to enable the analyst to gather evidence to refine, refute, or validate each hypothesis formulated in Phase II, and (2) to help the analyst compose the overall modus operandi of the attack.

Example. Consider a simple password checking app that compares the passwords stored in a server against strings submitted as passwords. The appAcceptsif the submitted string matches with a stored password. The app Rejects if the match fails.

At the end of Phase I, the analyst observes Thread.sleep()as a time-changing event. Based on the taint analysis result, the analyst also knows that there are conditions that are controlled by inputs. In the taint analysis result shown in Figure5.9, the secret (the passwords stored on the server) is colored red and input (the string submitted as password) is colored blue. When the taints originating from secret and the input come together the color changes to yellow in the taint flow graph.

The taints from the secret and the input come together when the input is compared against the secret passwords. The result of the comparison controls conditions C1 and C2 as shown in

the taint flow graph (Figure5.9).

In Phase II, the analyst hypothesizes that, depending on the comparison result of the secret passwords with the submitted password, two paths are created either by the condition C1 or

C2 such that time changing event Thread.sleep(25) happens on only one of those two paths.

Moreover, one character is compared at a time. Thus, the observed time difference can reveal to the attacker that the character matches. By submitting different strings for password and observing the time differences, the attacker can learn a secret password.

To validate the hypothesis, the analyst gathers evidence in Phase III to answer the following questions:

1. Do the conditions C1or C2create differential paths with and without theThread.sleep(25)

event?

2. Do the conditions depend on character-wise comparison of secret and input?

The EFG is useful for answering these questions. To answer the first question, the analyst can create the EFG for the eventThread.sleep(25). The resulting EFG in Figure5.10shows that the condition C1 actually governs a path with the event Thread.sleep(25). Thus, the execution

of Thread.sleep(25)is dependent on the comparison of the input and the secret passwords.

To answer the second question, the analyst can create the EFG with eventsThread.sleep(25), and the data flow events leading to the condition C1. If we include all such events, the EFG

can become huge and not be an effective program comprehension artifact. Our tool support a gradual expansion of the EFG by adding a few data flow events at a time. The backward data flow can be expanded one step at a time by adding the neighbors one data flow edge away at each step. We expand the EFG with the new data flow events corresponding to newly added neighbors. This EFG after expanding two steps is shown in Figure5.11. The new events added after expanding two steps are boxed. In this case, the new events were enough to reveal the character-wise comparison and thus no need to expand the EFG further.