Search

A new code-reuse attack, named Just-in-time (JIT) spraying attack, leverages the predictable generated JIT compiled code to launch an attack. It can circumvent the defenses such as data execution prevention and address space layout randomisation built-in in the modern operation system, which were thought the insurmountable barrier so that the attackers cannot construct the traditional code injection attacks. In this study, the authors describe JITSafe, a framework that can be applied to existing JIT-based virtual machines (VMs), in the purpose of preventing the attacker from reusing the JIT compiled code to construct the attack. The authors framework narrows the time window of the JIT compiled code in the executable pages, eliminates the immediate value and obfuscates the JIT compiled code. They demonstrate the effectiveness of JITSafe that it can successfully prevent existing JIT spraying attacks with low performance overhead.

Dynamic or Just-in-Time (JIT) compilation is essential to achieve high-performance emulation for programs written in managed languages, such as Java and C#. It has been observed that a conservative JIT compilation policy is most effective to obtain good runtime performance without impeding application progress on single-core machines. At the same time, it is often suggested that a more aggressive dynamic compilation strategy may perform best on modern machines that provide abundant computing resources, especially with virtual machines (VMs) that are also capable of spawning multiple concurrent compiler threads. However, comprehensive research on the best JIT compilation policy for such modern processors and VMs is currently lacking. The goal of this work is to explore the properties of single-tier and multitier JIT compilation policies that can enable existing and future VMs to realize the best program performance on modern machines. In this work, we design novel experiments and implement new VM configurations to effectively control the compiler aggressiveness and optimization levels ( if and when methods are compiled) in the industry-standard Oracle HotSpot Java VM to achieve this goal. We find that the best JIT compilation policy is determined by the nature of the application and the speed and effectiveness of the dynamic compilers. We extend earlier results showing the suitability of conservative JIT compilation on single-core machines for VMs with multiple concurrent compiler threads. We show that employing the free compilation resources (compiler threads and hardware cores) to aggressively compile more program methods quickly reaches a point of diminishing returns. At the same time, we also find that using the free resources to reduce compiler queue backup (compile selected hot methods early ) significantly benefits program performance, especially for slower (highly optimizing) JIT compilers. For such compilers, we observe that accurately prioritizing JIT method compiles is crucial to realize the most performance benefit with the smallest hardware budget. Finally, we show that a tiered compilation policy, although complex to implement, greatly alleviates the impact of more and early JIT compilation of programs on modern machines.

Dynamic or Just-in-Time (JIT) compilation is crucial to achieve acceptable performance for applications (written in managed languages, such as Java and C#) distributed as intermediate language binary codes for a virtual machine (VM) architecture. Since it occurs at runtime, JIT compilation needs to carefully tune its compilation policy to make effective decisions regarding 'if' and 'when' to compile different program regions to achieve the best overall program performance. Past research has extensively tuned JIT compilation policies, but mainly for VMs with a single compiler thread and for execution on single-processor machines. This work is driven by the need to explore the most effective JIT compilation strategies in their modern operational environment, where (a) processors have evolved from single to multi/many cores, and (b) VMs provide support for multiple concurrent compiler threads. Our results confirm that changing 'if' and 'when' methods are compiled have significant performance impacts. We construct several novel configurations in the HotSpot JVM to facilitate this study. The new configurations are necessitated by modern Java benchmarks that impede traditional static whole-program discovery, analysis and annotation, and are required for simulating future many-core hardware that is not yet widely available. We study the effects on performance of increasing compiler aggressiveness for VMs with multiple compiler threads running on existing single/multi-core and future many-core machines. Our results indicate that although more aggressive JIT compilation policies show no benefits on single-core machines, these can often improve program performance for multi/many-core machines. However, accurately prioritizing JIT method compilations is crucial to realize such benefits.

Trace-based JIT compilers identify frequently executed program paths at run-time and subsequently record, compile and optimize their execution. In order to improve the performance of the generated machine instructions, JIT compilers heavily rely on dynamic analysis of the code. Existing work treats the components of a JIT compiler as a monolithic whole, tied to particular execution semantics. We propose a formal framework that facilitates the design and implementation of a tracing JIT compiler and its accompanying dynamic analyses by decoupling the tracing, optimization, and interpretation processes. This results in a framework that is more configurable and extensible than existing formal tracing models. We formalize the tracer and interpreter as two abstract state machines that communicate through a minimal, well-defined interface. Developing a tracing JIT compiler becomes possible for arbitrary interpreters that implement this interface. The abstract machines also provide the necessary hooks to plug in custom analyses and optimizations.

In the face of widespread DEP and ASLR deploy- ment, JIT spraying brings together the best of code injection and code reuse attacks to defeat both defenses. However, to date, JIT spraying has been an x86-only attack thanks to its reliance on variable-length, unaligned instructions. In this paper, we finally extend JIT spraying to a RISC architecture by introducing a novel technique called gadget chaining, whereby high level code invokes short sequences of unintended and intended instructions called gadgets just like a function call. We demonstrate gadget chaining in an end-to-end JIT spraying attack against WebKit's JavaScriptCore JS engine on ARM and found that existing JIT spray mitigations that were sufficient against the x86 version of the JIT spraying attack fall short in the face of gadget chaining. I. INTRODUCTION It is no secret that programs are replete with bugs. Some of these bugs allow an attacker to subvert control of the program counter and divert execution away from its intended path; these are called control flow vulnerabilities. Unfortunately for a would-be attacker, a control flow vulnerability is not enough to execute arbitrary code on a remote machine. Defense mechanisms such as DEP and ASLR prevent attackers from writing code into a process's address space and decrease the likelihood that triggering a control flow vulnerability will cause an attacker's target code to execute. JIT spraying is an attack which defeats both DEP and ASLR by enabling an attacker to predictably influence large swaths of the victim process's executable memory. The attack exploits Just-in-Time compilers built into many recent lan- guage runtimes for the purpose of speeding up the performance of frequently-executed code, but it has only been demonstrated for the x86 architecture. More and more handheld devices, which are predominantly powered by ARM processors, are connecting to the Internet and running web browsers, making themselves candidates for remote exploitation. Since most modern web browsers implement a JavaScript runtime environ- ment with a fully-functioning JIT compiler, JIT spraying is a fantastic vector for attacking a browser. However, JIT spraying has historically been limited to the x86 architecture. In this paper, we challenge this trend and show that JIT spraying is indeed a viable attack against ARM.

Managed languages such as JavaScript are popular. For performance, modern implementations of managed languages adopt Just-In-Time (JIT) compilation. The danger to a JIT compiler is that an attacker can often control the input program and use it to trigger a vulnerability in the JIT compiler to launch code injection or JIT spraying attacks. In this paper, we propose a general approach called RockJIT to securing JIT compilers through Control-Flow Integrity (CFI). RockJIT builds a fine-grained control-flow graph from the source code of the JIT compiler and dynamically updates the control-flow policy when new code is generated on the fly. Through evaluation on Google's V8 JavaScript engine, we demonstrate that RockJIT can enforce strong security on a JIT compiler, while incurring only modest performance overhead (14.6% on V8) and requiring a small amount of changes to V8's code. Key contributions of RockJIT are a general architecture for securing JIT compilers and a method for generating fine-grained control-flow graphs from C++ code.

International audience; Due to the everlasting consumer demand for more complex applications, embedded systems have evolved both in terms of complexity and heterogeneity. The architecture of such systems often includes several kinds of different computing resources (DSPs, GPUs, etc.). As a consequence, software designers are facing significant performance and portability issues to target these devices. Software relies more and more on virtualization technologies to maximize portability of applications. In order to balance portability and performance, most virtualization technologies leverage Just-in-time (JIT) compilation to provide runtime optimized code from portable one. Nevertheless, the efficiency of JIT compilation depends on the ability to compensate its overhead with execution speedups of generated code. While most research efforts focus on limiting overhead of JIT compilation phases by reducing their occurrences, this paper investigates opportunities of speeding up JIT compilation itself. We first present a performance analysis of different JIT compilation technologies in order to identify hardware and software optimization opportunities. Second, we propose a solution based on a dedicated processor with specialized instructions for critical functions of JIT compilers. These specialized instructions provide an average 5x speedup on manipulations of associative arrays and dynamic memory allocation. Based on the LLVM framework, we show a 15% overall speedup on code generator's execution time. Because our specialized instructions are hidden behind standard libraries, we also argue that these instructions may be transparently reused for a wider range of applications.

JIT spraying has an assured spot in an attacker's toolkit for Web browser exploitation: With JIT spraying an attacker is able to circumvent even the most sophisticated defense strategies against code injection, including address space layout randomization (ASLR), data execution prevention (DEP) and stack canaries. In this paper, we present Lobotomy, an architecture for building injection-safe JIT engines. Lobotomy is secure by design: it separates compiler and executor of a JIT engine in different processes that share the memory regions containing the compiled code. This allows us to use least-privilege access rights for both processes, preventing memory regions to be mapped with write- and execute-rights at the same time. Our proof-of-concept implementation that modifies the well-known Fire fox JIT engine Trace monkey shows both the effectiveness and real-world feasibility of our architecture. Additionally, we provide a thorough evaluation of our version compared to an unmodified baseline and competing approaches.

Query is a functional language for querying XML data. In network environment, queries are generated dynamically and executed in interpretation way. This means query programs cannot be compiled in advance to achieve a high efficiency. The just-in-time (JIT) compliation technique base on method or trace have been propsed to utilize the compilation technique. Since queries are usually short and lack of user-defined functions, we think the trace-based JIT compilation is more applicable than the method-based compilation. In this paper, we propose a trace-based JIT compilation framework to improve the performance of Query execution. Program branches executed frequently are identified as traces and compiled into object codes. We also improve the trace detection technique. Interconnected traces are merged into a trace tree and compiled at runtime to avoid unnecessary overhead of execution environment alternation between interpretation and compilation. Experiment results show our trace-based JIT compilation is more efficient than interpretation and method-based JIT compilation.

Just-In-Time (JIT) Compilation is a technology used to improve speed of virtual machines that support dynamic loading of applications. It is better known as a technique that accelerates Java programs. Current JIT compilers are either huge in size or compile complete methods of the application requiring large amounts of memory for their functioning. This has made Java Virtual Machines for embedded systems devoid of JIT compilers. This paper explains a simple technique of combining interpretation with compilation to get a hybrid interpretation strategy. It also describes a new code generation technique that works using its self-code. The combination gives a JIT compiler that is very small (10K) and suitable for Java Virtual Machines for embedded systems.

Just-in-time compilers (JITs) are here to stay. Unfortunately, they also provide new capabilities to cyber attackers, namely the ability to supply input programs (in languages such as JavaScript) that will then be compiled to executable code. Once this code is placed and marked as executable, it can then be leveraged by the attacker.Randomization techniques such as constant blinding raise the cost to the attacker, but they significantly add to the burden of implementing a JIT. There are a great many JITs in use today, but not even all of the most commonly used ones randomize their outputs.We present librando, the first comprehensive technique to harden JIT compilers in a completely generic manner by randomizing their output transparently ex post facto. We implement this approach as a system-wide service that can simultaneously harden multiple running JITs. It hooks into the memory protections of the target OS and randomizes newly generated code on the fly when marked as executable.In order to provide "black box" JIT hardening, librando needs to be extremely conservative. For example, it completely preserves the contents of the calling stack, presenting each JIT with the illusion that it is executing its own generated code. Yet in spite of the heavy lifting that librando performs behind the scenes, the performance impact is surprisingly low. For Java (HotSpot), we measured slowdowns by a factor of 1.15x, and for compute-intensive JavaScript (V8) benchmarks, a slowdown of 3.5x.For many applications, this overhead is low enough to be practical for general use today.

Trace-based compilation uses dynamically-identified frequently-executed code sequences (traces) as units for compilation. We explore trace-based compilation in Java to see if a trace-based JIT compiler (trace-JIT) can address a limitation of method-based JIT compilers: limited compilation scope when dealing with those with largely flat execution profile. Although, trace-based compilation has gained popularity in dynamic scripting languages (e.g. TraceMonkey and pypy) or for embedded devices (e.g. Dalvik VM), the benefits and drawbacks of trace-JIT for large-scale applications have not yet been studied. We first describe the design and implementation of our trace-JIT with emphasis on efficient trace selection and code generation. Then we discuss how the trace selection algorithm affects the performance of a large-scale Java application server.

The Dalvik virtual machine is the main application platform running on Google's Android operating system for mobile devices and tablets. It is a Java Virtual Machine running a basic trace-based JIT compiler, unlike web browser JavaScript engines that usually run a combination of both method and trace-based JIT types. We developed a method-based JIT compiler based on the Low Level Virtual Machine framework that delivers performance improvement comparable to that of an Ahead-Of-Time compiler. We compared our method-based JIT against Dalvik's own trace-based JIT using common benchmarks available in the Android Market. Our results show that our method-based JIT is better than a basic trace-based JIT, and that, by sharing profiling and compilation information among each other, a smart combination of both JIT techniques can achieve a great performance gain.

As a code reuse technique, JIT spraying attack becomes popular on the JITed VM (Virtual Machine) (e.g., Javascript Engine, Flash Engine). Using a bug in web applications, an attacker can reuse the code generated by the JIT (Just-In-Time) compiler, which is used to optimize the performance of web applications. JIT spraying attacks can circumvent DEP and ASLR -- protection mechanisms of modern operating systems. Based on the observation that JIT spraying attack mostly uses the immediate operand of the arithmetic instruction to build a shellcode, we propose RIM, a technique that obfuscates the arithmetic operations in the JITed code and prevents attackers from reusing the native code to construct a malicious code. We implement a prototype on Tamarin flash engine and demonstrate the effectiveness of RIM. Experimental results show that RIM's overhead is very low (less than 1%). And RIM greatly improves the security functionality of JIT compilers.

Adobe Flash is present on nearly every PC, and it is increasingly being targeted by malware authors. Despite this, research into methods for detecting malicious Flash files has been limited. Similarly, there is very little documentation available about the techniques commonly used by Flash malware. Instead, most research has focused on JavaScript malware. This paper discusses common techniques such as heap spraying, JIT spraying, and type confusion exploitation in the context of Flash malware. Where applicable, these techniques are compared to those used in malicious JavaScript. Subsequently, FlashDetect is presented, an offline Flash file analyzer that uses both dynamic and static analysis, and that can detect malicious Flash files using ActionScript 3. FlashDetect classifies submitted files using a naive Bayesian classifier based on a set of predefined features. Our experiments show that FlashDetect has high classification accuracy, and that its efficacy is comparable with that of commercial anti-virus products.

JIT spraying is a new code-reuse technique to attack virtual machines based on JIT (Just-in-time) compilation. It has proven to be capable of circumventing the defenses such as data execution prevention (DEP) and address space layout randomization(ASLR), which are effective for preventing the traditional code injection attacks. In this paper, we describe JITDefender, an enhancement of standard JIT-based VMs, which can prevent the attacker from executing arbitrary JIT compiled code on the VM. Thereby JITDefender can block JIT spraying attacks. We prove the effectiveness of JITDefender by demonstrating that it can successfully prevent existing JIT spraying exploits. JITDefender reports no false positives when run over benign actionscript/javascript programs. In addition, we show that the performance overhead of JITDefender is low.

DCG (Dynamic Code Generation) technologies have found widely applications in the Web 2.0 era, Dion Blazakis recently presented a Flash JIT-Spraying attack against Adobe Flash Player that easily circumvented DEP and ASLR protection mechanisms built in modern operating systems. We have generalized and extended JIT Spraying into DCG Spraying. Based our analyses on this abstract model of DCG Spraying, we have found that all mainstream DCG implementations (Java/ JavaScript/ Flash/ .Net/ SilverLight) are vulnerable against DCG Spraying attack, and none of the existing ad hoc defenses such as compilation optimization, random NOP padding and constant splitting provides effective protection. Furthermore, we propose a new protection method, INSeRT, which combines randomization of intrinsic elements of machine instructions and randomly planted special trapping snippets. INSeRT practically renders the "sprayed code" ineffective, while alerts the host program of ongoing attacking attempts. We implemented a prototype of INSeRT on the V8 JavaScript engine, and the performance overhead is less than 5%, which should be acceptable in practical application.

JIT compilation is a model of execution which translates at run time critical parts of the program to a low level representation. Typically a JIT compiler produces machine code from an intermediate bytecode representation. This paper considers a hardware JIT compiler targeting FPGAs, which are digital circuits configurable as needed to implement application specific circuits. Recent FPGAs in the Xilinx Virtex family are particularly attractive for hardware JIT because they are reconfigurable at run time, they contain both CPUs and reconfigurable logic, and their architecture strikes a balance of features. In this paper we discuss the design of a hardware architecture and compiler able to dynamically enhance the instruction set with hardware specialized instructions. A prototype system based on the Xilinx Virtex family supporting hardware JIT compilation is described and evaluated.

Dynamic Binary Translation (DBT) is the key technology behind cross-platform virtualization and allows software compiled for one Instruction Set Architecture (ISA) to be executed on a processor supporting a different ISA. Under the hood, DBT is typically implemented using Just-In-Time (JIT) compilation of frequently executed program regions, also called traces . The main challenge is translating frequently executed program regions as fast as possible into highly efficient native code. As time for JIT compilation adds to the overall execution time, the JIT compiler is often decoupled and operates in a separate thread independent from the main simulation loop to reduce the overhead of JIT compilation. In this paper we present two innovative contributions. The first contribution is a generalized trace compilation approach that considers all frequently executed paths in a program for JIT compilation, as opposed to previous approaches where trace compilation is restricted to paths through loops. The second contribution reduces JIT compilation cost by compiling several hot traces in a concurrent task farm. Altogether we combine generalized light-weight tracing, large translation units, parallel JIT compilation and dynamic work scheduling to ensure timely and efficient processing of hot traces. We have evaluated our industry-strength, LLVM-based parallel DBT implementing the ARCompact ISA against three benchmark suites (EEMBC, BioPerf and SPEC CPU2006) and demonstrate speedups of up to 2.08 on a standard quad-core Intel Xeon machine. Across short- and long-running benchmarks our scheme is robust and never results in a slowdown. In fact, using four processors total execution time can be reduced by on average 11.5% over state-of-the-art decoupled, parallel (or asynchronous ) JIT compilation.