Read the original article here.

---

The Forbidden Code: Understanding JIT Spraying

In the shadowy realm of exploit development, where programmers dance on the edge of system boundaries and security measures, certain techniques are born out of necessity and ingenuity. JIT spraying is one such technique – a sophisticated attack that leverages the very tools designed to improve software performance, turning them into weapons against conventional defenses.

While schools teach you robust software design and standard programming paradigms, they rarely delve into the nuances of memory corruption, control flow manipulation, and the clever bypasses used by adversaries. Understanding techniques like JIT spraying is crucial for both defense and a deeper appreciation of system internals. It's about seeing code not just as logic, but as bytes in memory, ready to be misinterpreted or commandeered.

This guide explores JIT spraying in detail, dissecting its mechanics and revealing how it circumvents modern security protections.

The Battlefield: Modern Security Defenses

Before understanding JIT spraying, we must first grasp the defenses it's designed to defeat. Two primary bastions of modern security are Address Space Layout Randomization (ASLR) and Data Execution Prevention (DEP).

Address Space Layout Randomization (ASLR): A security technique that randomly arranges the address space positions of key data areas, including the base of the executable and the positions of the stack, heap, and libraries. This makes it difficult for an attacker to predict the target addresses of jumps, return points, or gadget locations in ROP attacks, thus hindering exploitation via control flow hijacking.

Data Execution Prevention (DEP): A system-level security feature that marks certain memory areas (typically data segments like the heap or stack) as non-executable. This prevents malicious code injected into these data areas from being run, blocking classic buffer overflow attacks where shellcode is written to the stack and executed by overwriting a return address.

These two techniques, especially when combined, significantly raise the bar for attackers. ASLR makes predicting where code or data will be difficult, and DEP prevents code from being executed directly from data locations where vulnerabilities (like buffer overflows) often allow injection.

So, how does an attacker execute arbitrary code in a system protected by ASLR and DEP? This is where JIT spraying comes in.

The Target: Just-In-Time (JIT) Compilers

JIT spraying attacks specifically target systems or applications that use Just-In-Time (JIT) compilation.

Just-In-Time (JIT) Compilation: A method of executing computer code that involves compilation during execution of a program rather than before execution. It translates source code or intermediate code (like bytecode) into native machine code at runtime. JIT compilers are often used in environments where performance is critical, such as web browsers (for JavaScript), virtual machines (like Java's JVM), or scripting environments (like ActionScript in Adobe Flash).

The key characteristic of a JIT compiler relevant to this exploit is its fundamental need to generate executable code in memory during runtime. The compiler takes intermediate instructions and translates them into machine code bytes, which it then writes to a memory region that must be marked as executable so the CPU can run it.

This requirement creates an inherent conflict with DEP. While DEP aims to prevent execution from data regions, a JIT compiler needs to write executable code into a dynamically allocated memory region. For this reason, memory allocated by a JIT compiler to store its compiled output is typically exempted from DEP restrictions. It is marked as executable, or lives in a memory segment that is designated for executable code.

This executable memory region, dynamically allocated by the JIT, becomes the perfect staging ground for an attacker seeking to bypass DEP.

The Weapon: JIT Code Generation as Data

The core idea behind JIT spraying is to manipulate the JIT compiler's input (e.g., JavaScript or ActionScript code) in such a way that its output (native machine code) contains sequences of bytes that the attacker can control and execute.

Consider a simple operation in a scripting language: a = b ^ c;. A JIT compiler will translate this into native assembly instructions, likely using registers and an XOR operation. The specific bytes generated depend on the architecture (e.g., x86, ARM) and the specific JIT implementation.

The crucial insight, attributed to researcher Dion Blazakis, is that attackers can influence the generated machine code bytes by carefully selecting constant values and operations in the input script.

Let's look at the provided example: using repeated XOR operations with specific constant values. Input script snippet (conceptual):

// Assume 'a' is a register/variable the JIT maps to EAX
a = 0x11223344;
a = a ^ 0x44332211;
a = a ^ 0x44332211;

A JIT compiler might translate this into the following x86-32 assembly and its corresponding byte code:

; a = 0x11223344;
mov eax, 0x11223344
; Bytes: b8 44 33 22 11

; a = a ^ 0x44332211;
xor eax, 0x44332211
; Bytes: 35 11 22 33 44

; a = a ^ 0x44332211;
xor eax, 0x44332211
; Bytes: 35 11 22 33 44

Concatenated, the byte sequence generated by the JIT might look like: b8 44 33 22 11 35 11 22 33 44 35 11 22 33 44.

An attacker can craft input code that generates specific byte sequences. By carefully choosing constants (like 0x11223344 and 0x44332211) and operations (like mov and xor), they can effectively embed desired machine code instructions within the legitimate code generated by the JIT. These embedded sequences are often referred to as "gadgets" or simply the attacker's intended code payload.

The Tactic: JIT Spraying

The name "JIT spraying" comes from combining JIT compilation with a technique called heap spraying.

Heap Spraying: An exploit technique used to facilitate other memory corruption vulnerabilities (like buffer overflows that don't allow direct code injection). It involves allocating large blocks of memory (often on the heap) and filling them with copies of the attacker's payload (e.g., NOP sleds followed by shellcode). The goal is to fill a large, predictable region of the address space, increasing the probability that a control flow hijack (even one with an unpredictable jump target, as is often the case with ASLR bypass attempts) will land within the sprayed region, thus executing the payload.

In JIT spraying, instead of spraying NOP sleds and shellcode directly into data memory (which DEP would block), the attacker sprays large amounts of JIT-generated code into memory. They write input script code that, when compiled by the JIT, produces the desired sequence of machine code bytes (the attacker's payload or gadgets). They then repeat this input script many times, causing the JIT to compile and allocate many copies of the resulting machine code in memory.

Since the memory allocated by the JIT is executable (to bypass DEP), and the attacker has filled a large area with predictable, attacker-controlled code sequences (to bypass ASLR's unpredictability), the stage is set for the final step.

Executing the Coup: Redirecting Control Flow

With the JIT-generated payload sprayed across an executable memory region, the attacker needs a way to force the program's execution flow into this region. This is typically achieved by exploiting another, often simpler, memory corruption vulnerability.

Common vulnerabilities used for control flow redirection include:

• Buffer Overflows: Writing past the end of a buffer to overwrite adjacent data, such as a function pointer, a return address on the stack, or metadata that, when processed, causes a jump to a controlled address.
• Use-After-Free (UAF): Exploiting a dangling pointer that still points to memory that has been freed. If this memory is later reallocated with attacker-controlled data (like a crafted object with a malicious virtual function pointer), calling a method through the dangling pointer can redirect execution.

The attacker exploits one of these vulnerabilities to overwrite a control flow mechanism (like a function pointer or return address) with an address somewhere within the large, sprayed region of JIT-generated code. Because ASLR is still active and the exact location of the JIT memory is somewhat randomized, the spraying is essential. By filling a large range of possible addresses with copies of the payload, the attacker significantly increases the chance that the (potentially slightly misaligned) jump target resulting from the vulnerability will land within the sprayed region.

Once the CPU jumps to an address within the sprayed JIT code, it begins executing the instructions the attacker carefully crafted in their input script.

The Nasty Twist: Instruction Misinterpretation

A particularly potent aspect of JIT spraying on architectures like x86 and x86-64 is the ability to exploit instruction misinterpretation.

x86 architecture uses variable-length instructions. The CPU determines where one instruction ends and the next begins by looking at the opcode and prefix bytes. If execution jumps into the middle of what the compiler intended to be a single instruction, the CPU will start interpreting bytes from that arbitrary point, potentially seeing a completely different instruction sequence.

Consider the example byte sequence generated earlier: b8 44 33 22 11 35 11 22 33 44 35 11 22 33 44. The compiler intended this as: b8 44 33 22 11 (mov eax, 0x11223344) 35 11 22 33 44 (xor eax, 0x44332211) 35 11 22 33 44 (xor eax, 0x44332211)

If the attacker's control flow hijack redirects execution not to the start (b8) but to the second byte (44), the CPU will start interpreting the sequence from there: 44 33 22 11 35....

On x86, 44 is the opcode for INC ESP (increment the stack pointer). The CPU will then read the next byte(s) as operands for whatever instruction starts with the bytes immediately following 44.

Looking at the sequence 44 33 22 11 35 11 22 33 44:

• Starting at byte 1 (44):
  • 44 -> inc esp (1-byte instruction on some encodings, depends on operand size prefixes not shown here, but 44 is often an inc variant). The example shows inc %esp.
  • The next byte is 33. The CPU reads from 33 22 11 35...
  • 33 22 -> xor esp, DWORD PTR [edx] (or similar, 33 is XOR, 22 is modR/M byte indicating [edx] operand). The example shows xor (%edx),%esp.
  • The next bytes are 11 35 11 22 33 44.
  • 11 35 11 22 33 44 -> adc DWORD PTR ds:0x44332211, esi (or similar, 11 is ADC, 35 indicates immediate operand + address mode). The example shows adc %esi,0x44332211.
  • And so on...

By strategically crafting the intended byte sequence generated by the JIT, an attacker can predict and control the unintended instruction sequences that result from jumping into the middle of the bytes. This allows them to create complex chains of small instructions, similar to Return-Oriented Programming (ROP), but using JIT-generated code instead of existing library code. These instruction sequences can perform actions like modifying memory permissions, loading malicious libraries, or jumping to a final shellcode payload located elsewhere.

This trick is particularly effective on architectures with variable-length instructions like x86. On architectures with fixed-length instructions, such as ARM, jumping into the middle of an instruction is generally not possible, limiting this specific form of instruction misinterpretation.

Real-World Deployments

JIT spraying has been a significant technique in exploit development, particularly for targeting scripting engines commonly found in widely distributed software.

Historically, prominent targets included:

• Adobe Flash: Its ActionScript engine used a JIT compiler, making it a prime target for JIT spraying attacks delivered via malicious Flash content embedded in websites or documents.
• PDF Readers: PDF viewers that included support for JavaScript (used for interactive forms, etc.) often featured JIT compilers for performance, presenting another attack vector.

These applications were ubiquitous, making vulnerabilities in their JIT implementations high-value targets for attackers seeking to compromise user systems.

Defense Against the Dark Arts: Mitigation

Protecting against JIT spraying requires addressing the core vulnerabilities that enable it:

1. Reduce the attack surface: If an application doesn't need a JIT compiler for a specific feature (e.g., JavaScript in a PDF reader), disable it. This eliminates the executable JIT memory region entirely.
2. Harden the JIT:
   • Make JIT output less predictable: Modify the JIT to generate code in a way that makes it harder for an attacker to control the byte sequences precisely. For example, inserting random NOP instructions or varying the output code structure.
   • Implement stricter validation: Improve validation of input scripts to detect malicious patterns intended to generate specific byte sequences.
   • Limit the size of JIT regions: Restrict the amount of memory a JIT can allocate for executable code, making large-scale spraying more difficult or detectable.
3. Improve ASLR and reduce memory corruption vulnerabilities: While JIT spraying bypasses DEP, it often still relies on a separate memory corruption bug (buffer overflow, UAF) to redirect control flow. Patching these underlying vulnerabilities or improving ASLR entropy and techniques like pointer authentication can make the initial control flow hijack harder to achieve, even if JIT code is present.
4. Segment JIT memory: Explore techniques to separate JIT-generated code into smaller, potentially non-contiguous regions, making large, predictable sprays less effective.

While JIT spraying remains a powerful technique, ongoing security research and hardening efforts have made it more challenging to execute reliably in modern, fully-patched software compared to a decade ago. However, understanding its principles is vital, as attackers constantly adapt, finding new targets and variations of old techniques.

Conclusion

JIT spraying exemplifies the attacker's mindset: finding unintended pathways and leveraging system features against their security goals. By exploiting the necessary executable memory regions created by JIT compilers and using techniques like heap spraying and instruction misinterpretation, attackers can bypass fundamental defenses like DEP and ASLR. Studying such "forbidden" techniques isn't about promoting malicious activity, but about gaining a deep, practical understanding of how systems truly work at the low level and how to build more resilient software in the face of sophisticated threats. It's a critical piece of knowledge for anyone serious about software security.