Efficient approach to fuzzing interpreters Marcin Dominiak Wojciech Rauner Samsung R&D Institute Poland Samsung R&D Institute Poland [email protected] [email protected] Abstract ten fuzzers utilize multiple approaches, algorithms and heuristics in order to achieve high effectiveness. Fuzzing has started to gain more recognition over the Fuzzing, as a technique, has been proven to be past years. The basic concept behind it is passing ran- highly efficient at discovering bugs and security vul- dom or otherwise procedurally generated data as in- nerabilities. As an example, Zalewski | author of put to the tested software. Multiple fuzzers emerged American Fuzzy Lop (AFL) [1] and Vyukov | au- which have an impressive number of bugs discovered. thor of syzkaller [2], display an impressive number However, their applicability in fuzzing targets requiring of issues discovered by their tools. A wide range of highly structured yet arbitrarily nuanced input data, programs is continuously fuzzed by OSS-fuzz [3] | such as interpreters, is questionable. At the same time, an initiative by Google which allows maintainers of an interpreter's input is often untrusted. This, coupled open source projects to integrate their codebase with with their widespread usage, makes them a high prior- the ClusterFuzz, which then automatically synchro- ity target for security research, especially considering nizes and tests the software using Google's infrastruc- the interpreter's large codebase and high complexity. ture. As of writing this paper, more than 8000 bugs In this paper, we introduce the concept of combining were reported by the OSS-fuzz project. coverage guided fuzzing with synthesizing code given Interpreters of various languages are commonly found arbitrary input data. We will discuss the implemen- in modern software as they allow developers to create a tation of this idea in the Fluff project and describe more engaging and interactive user experience. One of its integration with American Fuzzing Lop | an the most prominent uses of interpreters are JavaScript open-source fuzzer. We show that by using Fluff execution engines embedded in web browsers. As of we can achieve larger code coverage than with current, March 2019, TIOBE [4], which measures popularity state of the art solutions. of programming languages, has ranked JavaScript as the 7th most popular technology. Other popular in- terpreted technologies include Python, PHP and Ruby. 1 Introduction All of those technologies are not only widely used, but also highly complex and constantly developed, which 1.1 Overview makes them perfect security research targets. Interpreters are a class of software which is difficult Fuzzing is a technique used to automatically test soft- to fuzz. The reason for that is the ease with which they ware. A basic fuzzer could generate random data and reject invalid inputs. On one hand interpreters perform pass it as input to the target. Modern fuzzers often uti- multiple validations on the input in order to reject any lize automatic analysis of the program source code or erroneous source codes, on the other they accept and instrumentation in order to gather information about execute a very wide range of valid codes. This results in the program and control flow. They use that informa- a situation where most test cases generated by a fuzzer tion as a feedback in order to improve the quality of the are quickly rejected, thus yielding low test coverage. test cases. A common metric to measure the quality of an input is, is checking whether the target program be- haved in a way which has not yet been observed (for ex- 1.2 Attack scenarios ample the program reached a location in the code which has not been visited before, or it crashed). Fuzzers Exploiting vulnerabilities in an interpreter is especially which track executed branches visited across runs and interesting as it can change the scope of an attack by try to maximize this value are called coverage guided. escaping the restricted execution environment. To vi- Fuzzers can utilize mutators, which modify either pre- sualize the risks connected with security vulnerabilities viously used inputs or a seed provided by a user launch- present in this class of software, we will enumerate sev- ing the tool, in order to generate new test cases. Of- eral possible attack scenarios: 1 • Web browsers Grey-box fuzzing is a technique of incorporating If a malicious entity controls a website (either by information about the target to the fuzzer. In the case legitimately owning it or by compromising an ex- of fuzzing interpreters, this can be done by providing isting service) it can craft JavaScript code which keywords or whole code snippets which the fuzzer in- will be executed by default in the browser of each corporates into the generated test cases. AFL can work user visiting the webpage. Exploiting the execu- in this way if a user provides it with a list of keywords. tion engine and browser could lead to the attackers Another well known tool in this category is jsfunfuzz gaining complete control over the visitor's system. [10], which works by constructing JavaScript code snip- pets and executing them. Those snippets are gen- • Online execution services erated using predefined templates, magic values, key- Some online services offer a functionality to ex- words and hard-coded randomness. This project does ecute code provided by the user (for example not use any instrumentation nor symbolic execution. It ideone [5]). Such services can be used to quickly is also tightly coupled with JavaScript and in particu- test, share code or explain certain features. While lar, with Mozilla's SpiderMonkey engine. Langfuzz those services take great measures to make sure [11] is another fuzzer in this category, which utilizes that executing arbitrary code does not compro- both generative and mutative approaches in order to mise their safety, exploiting one of the interpreters create new test cases. It is however a Mozilla internal might allow an attacker to gain control of the sys- tool. This approach can be effective, as it is easier for tem or gather more information about its internals. this type of fuzzers to create a valid program and pass parser, thus reaching backend of the interpreter. Unfor- • Continuous integration systems tunately, fuzzers in this category share the downsides of Those systems are integrated with version control both grammar based approaches and generic mutative software and allow developers to define tasks which fuzzers, as they are either limited by the hardcoded val- are to be executed periodically. A common task ues and snippets (as is the case with jsfunfuzz), or is building the application and running tests. A not limited enough and can't reliably pass parser (like malicious user could craft code specifically to ex- AFL with dictionary). ploit the execution engine in order to take control csmith [12] is a tool which synthesizes completely or otherwise attack the system itself, or even the valid C programs and passes them for compilation and machines running it. execution in multiple compilers. The outputs are then executed and the behavior of generated files is moni- • Social engineering tored in order to spot errors in logic. Any crashes dur- An attacker could try to post malicious code to on- ing the compilation process are also stored for analysis. line developer forums (like StackOverflow [6]) and csmith is a mature and highly efficient tool, however, ask for help, or otherwise try to trick users to exe- it does not cooperate with any fuzzer, nor employ any cute his specifically crafted code, hoping to exploit mutative approach, which could increase its effective- and compromise systems of people thinking that ness. csmith focuses on finding bugs in logic, which they are helping someone. cause the compiler to generate incorrect machine code. It also supports only C language. 1.3 Related work Formal verification could allow to ensure, in a provable way, that a piece of software is secure and cor- Grammar based approaches require a user-provided rect. It is still difficult to perform formal verification formal grammar and generate a script which will out- of projects as big as interpreters and compilers due to put test cases compliant with that grammar. A sample the amount of required work and computational power, tool utilizing this approach is Grammarinator [7]. Al- however, there is an ongoing effort to create a fully ver- though this approach does not support any sort of feed- ified compiler | compcert [13]. We are not aware of back loop by design, it can be implemented in a way any ongoing effort aiming to formally verify any exist- which does. Vegard has described in his blog post [8] ing interpreter. his approach to fuzzing GCC [9] compiler, which is also grammar based but uses AFL as the backend and there- 1.4 Paper outline fore utilizes a feedback loop. This approach is flexible, because one can create an input grammar for many pro- Section 2 describes different levels of fuzz testing. Sec- gramming languages. However, it is impossible to en- tion 3 introduces Fluff, which is our contribution to force certain properties, which are sometimes desired, this field. That section contains description of its de- using context free grammars (further elaborated in ap- sign, implementation and limitations, as well as ex- pendix A.1). tensions and design choices. Section 4 describes the 2 methodology used to evaluate selected approaches to fuzzing. Section 5 presents results of our research and = += comparison of Fluff with other approaches to fuzzing interpreters. Finally, section 6 summarizes findings of x 5 x 7 our work, as well as presents several further research ideas. Figure 1: Decomposition of the sample program into AST 2 Fuzzing interpreters Apart from syntactical correctness we want to en- In fuzzing we can differentiate between multiple levels force semantical correctness, in order to make sure, that of increasing test case quality [14].