JIT spraying

JIT spraying is a class of <a href="/facts/Computer_security_exploit/EdlqsRJM">computer security exploit</a> that circumvents the protection of <a href="/facts/Address_space_layout_randomization/K6lMxWTr">address space layout randomization</a> and <a href="/facts/Data_execution_prevention/WcI79ME5">data execution prevention</a> by exploiting the behavior of <a href="/facts/Just-in-time_compilation/rEYDsd8l">just-in-time compilation</a>. It has been used to exploit the <a href="/facts/PDF/C9Mn1vYL">PDF</a> format and <a href="/facts/Adobe_Flash/3Lrp9JuH">Adobe Flash</a>.
A <a href="/facts/Just-in-time_compiler/rEYDsd8l">just-in-time compiler</a> (JIT) by definition produces code as its data. Since the purpose is to produce executable data, a JIT compiler is one of the few types of programs that cannot be run in a no-executable-data environment. Because of this, JIT compilers are normally exempt from data execution prevention. A JIT spray attack does <a href="/facts/Heap_spraying/yfz8YhM9">heap spraying</a> with the generated code.
To produce exploit code from JIT, an idea from Dion Blazakis is used. The input program, usually <a href="/facts/JavaScript/XhhIIEsl">JavaScript</a> or <a href="/facts/ActionScript/xtDQb0wR">ActionScript</a>, typically contains numerous constant values that can be erroneously executed as code. For example, the <a href="/facts/Exclusive_or/FHyr7hGQ">XOR</a> operation could be used:

var a = (0x11223344^0x44332211^0x44332211^ ...);

JIT then will transform bytecode to native x86 code like:

0: b8 44 33 22 11 mov $0x11223344,%eax mov eax,0x11223344
5: 35 11 22 33 44 xor $0x44332211,%eax xor eax,0x44332211
a: 35 11 22 33 44 xor $0x44332211,%eax xor eax,0x44332211

The attacker then uses a suitable bug to redirect code execution into the newly generated code. For example, a <a href="/facts/Buffer_overflow/uMFduL4B">buffer overflow</a> or <a href="/facts/Use_after_free/WowANVwK">use after free</a> bug could allow the attack to modify a <a href="/facts/Function_pointer/PEhvvsQB">function pointer</a> or return address.
This causes the CPU to execute instructions in a way that was unintended by the JIT authors. The attacker is usually not even limited to the expected instruction boundaries; it is possible to jump into the middle of an intended instruction to have the CPU interpret it as something else. As with non-JIT <a href="/facts/Return-oriented_programming/ukDyRgsh">ROP</a> attacks, this may be enough operations to usefully take control of the computer. Continuing the above example, jumping to the second byte of the "mov" instruction results in an "inc" instruction:

1: 44 inc %esp inc esp
2: 33 22 xor (%edx),%esp xor esp,DWORD PTR [edx]
4: 11 35 11 22 33 44 adc %esi,0x44332211 adc DWORD PTR ds:0x44332211,esi
a: 35 11 22 33 44 xor $0x44332211,%eax xor eax,0x44332211

<a href="/facts/X86/Kypq5fgu">x86</a> and <a href="/facts/X86-64/cyWvUFlP">x86-64</a> allow jumping into the middle of an instruction, but not fixed-length architectures like <a href="/facts/ARM_architecture/SALsYA79">ARM</a>.
To protect against JIT spraying, the JIT code can be disabled or made less predictable for the attacker.

JIT spraying open-in-new

JIT spraying