Analyzing Dynamic Code

Abstract

Dynamic languages, such as JavaScript, employ string-to-code primitives to turn dynamically generated text into executable code at run-time. These features make standard static analysis extremely hard if not impossible, because its essential data structures, i.e., the control-flow graph and the system of recursive equations associated with the program to analyze, are themselves dynamically mutating objects. Nevertheless, assembling code at run-time by manipulating strings, such as by eval in JavaScript, has been always strongly discouraged, since it is often recognized that “ eval is evil ,” leading static analyzers to not consider such statements or ignoring their effects. Unfortunately, the lack of formal approaches to analyze string-to-code statements pose a perfect habitat for malicious code, that is surely evil and do not respect good practice rules, allowing them to hide malicious intents as strings to be converted to code and making static analyses blind to the real malicious aim of the code. Hence, the need to handle string-to-code statements approximating what they can execute, and therefore allowing the analysis to continue (even in the presence of dynamically generated program statements) with an acceptable degree of precision, should be clear. To reach this goal, we propose a static analysis allowing us to collect string values and to soundly over-approximate and analyze the code potentially executed by a string-to-code statement.

Improving Dynamic Code Analysis by Code Abstraction

“…Recently, several techniques have been proposed for JavaScript code obfuscation 1 , meaning that also client-side code protection is becoming an increasingly important problem to be tackled by the research community and by practitioners. Hence, it is not always possible to simply ignore eval without accepting to lose the possibility of analyzing the rest of the program [3]. str = " x =5"; while ( i < 3) { str = str + "5"; i = i + 1; } str = str + ";"; eval ( str ) ; The Context: Analyzing Dynamic Code.…”

“…This happens because program data structures, such as the control-flow graph and the system of recursive equations associated with the program in question, are themselves dynamically mutating objects. Recently [3], the problem of analyzing dynamic code has been tackled by treating code as any other dynamic structure that can be statically analyzed by abstract interpretation, and to treat the abstract interpreter as any other program function that can be recursively called. In particular, in [3], we provide a static analyzer architecture for a core dynamic language, containing non-removable eval statements, that still has some limitation in terms of precision but provides the necessary ground for studying more precise solutions to the problem.…”

“…The Problem: Improve Precision Analysis by Abstracting Code. This analysis provides a first step towards the analysis of dynamic languages but still has some important precision loss [3]. In particular, there are particular forms of FA (which occur when the string is dynamically generated by loops) avoiding the possibility of generating a control flow graph (CFG) able to approximate the code executed by an eval.…”

“…In particular, there are particular forms of FA (which occur when the string is dynamically generated by loops) avoiding the possibility of generating a control flow graph (CFG) able to approximate the code executed by an eval. For instance, when the FA accepts a language such as x=(5) n ; n > 0 , the analysis in [3] cannot extract, from the FA, the CFG approximating the eval argument. In order to better explain the problem, consider the code in Fig.…”

“…1, we draw the automaton A representing the abstract value of str before the eval execution. The problem is that A has a cycle not involving a whole statement [3]. This situation makes the analyzer unable to build a CFG over-approximating the code potentially executed since, intuitively, such a CFG should be infinite.…”