Each Android app runs in its own VM, with every VM allocated a limited heap size for creating new objects. Neither the app nor the OS differentiates between regular objects and objects that contain security sensitive information like user authentication credentials, authorization tokens, en/decryption keys, PINs, etc. These critical objects like any other object are kept around in the heap until the OS hits a memory constraint and realizes that it needs more memory. The OS then chooses to invoke garbage collector in order to reclaim memory from the apps. Java does not provide explicit APIs to reclaim memory occupied by objects. This leaves a window of time where the security critical objects live in the memory and wait to be garbage collected. During this window a compromise of the app can allow an attacker to read the credentials. This is a needless risk every Android application lives with today. To exacerbate the situation, apps today heavily make use of Identity providers to implement Open ID/OAuth based authentication and authorization.
In this paper we propose a novel approach to determine at every program statement, which security critical objects will not be used by the app in the future. An Android application once compiled, has all the information needed to determine this. Using results from our data flow analysis [1] we can decide to flush out the security sensitive information from the objects immediately after their last use, thereby preventing an attacker who has compromised the app from reading security critical information. This way an app can truly provide defence in depth, protecting sensitive data even after a compromise.
We propose a new tool called Androsia, which uses static program analysis techniques to perform a summary based [2] interprocedural data flow analysis to determine the points in the program where security sensitive objects are last used (so that their content can be cleared). Androsia then performs bytecode transformation of the app to flush out the secrets resetting the objects to their default values. The data-flow analysis associates two elements with each statement in the unit control flow graph called flow sets: one in-set and one out-set. These sets are (1) initialized, then (2) propagated through the unit graph along statement nodes until (3) a fixed point is reached.
We leverage the power of Soot [3], a static Java-bytecode analysis framework, to identify the points in the program where an object is last used (LUP). The detection of Last Usage Point (LUP) of objects, requires analysis of methods in a reverse topological order of their actual execution order; which means that the callee method will be analyzed before the caller method. We construct flow functions for the analysis and use them to propagate the data flow sets [4]. The flow functions are as follows:
Out(i) = φ if S(i) is exit node in CFG
= ∪ {In(j)} | where S(j) is the set of all successor statements of S(i) | otherwise
In(i) = Out(i) ∪ Gen(i); where
Gen(i) = {var(y)} | if S(i) is of the form: x = y
= {var(y)} | if S(i) is of the form: x = if(y)
= {var(y)} | if S(i) is of the form: x = while(y)
= {p(i)} | if S(i) is of the form: x = f(p)
= {φ} | otherwise
(In the interest of space: pls. refer [1] to know more about how the flow functions work in a data flow analysis)
In our analysis, the flow sets are propagated backwards in the Unit graph [5]. The analysis result corresponding to a method is kept as a summary for that method and is propagated to caller methods at the method call site. Hence giving rise to an inter-procedural summary based analysis.
Using the results from this analysis we then perform bytecode transformation on the target app to remove sensitive information from the objects at the identified program points from our analysis. As a case-study, we take Android apps and manifest the security that Androsia has to offer.
[1] Data flow analysis, https://en.wikipedia.org/wiki/Data-flow_analysis
[2] D. Yan, G. Xu, and A. Rountev. Rethinking soot for summary-based wholeprogram analysis. In Proceedings of the ACM SIGPLAN International Workshop on State of the Art in Java Program Analysis, SOAP ’12, pages 9–14, New York, NY, USA, 2012. ACM
[3] Soot: a Java Optimization Framework. http://www.sable.mcgill.ca/soot/
[4] Implementing an intra procedural data flow analysis in Soot. https://github.com/Sable/soot/wiki/Implementing-an-intra-procedural-data-flow-analysis-in-Soot
[5] UnitGraph. https://www.sable.mcgill.ca/soot/doc/soot/toolkits/graph/UnitGraph.html