Seminar Course : Code Reuse
attacks and defenses against
them(IN2107)
Jump-Oriented Programming
Name:Urdhwa Golwalker
Matrikel-Nr:03688064
1
Introduction
History of code reuse attacks….
1. Code Injection attacks
2. Return into libc technique
3. ROP attacks=> Overwrites stacks
Defense against ROP:
-DynIMA[1].
-DROP[2]
-Return-less approach =>Eliminate all return instructions
2
Introduction(contd.)
Silent features of ROP
-Turing complete=>fully functional "language" that an attacker can use to
make a compromised machine perform any operation desired[3]
-automated techniques=>straightforward process[3]
- Real potential as Shown by Checkoway et al[4]
This leads to a need for advent of new mechanism for implementing this attack…
3
Advent of Jump Oriented Programming(JOP)
What should we do to continue to perform code-reuse attack?
-Abandons all reliance on the stack for control flow
-Use indirect jmp statements for gadget discovery and chaining
Principally, change the format of ROP  (JOP)
Impact of change
-No defense mechanism of ROP will work for this.
Exception=>Systems that enforce full control flow integrity
But they are not widely deployed.
4
Jump Oriented Programming(JOP)
What's the difference?
-In ROP, we use ret as an ending of gadget to chain multiple frames. But in JOP, we
use jmp as an ending of gadget.
New problem comes
-the attacker aim to make sequence of execution, but with jmp as ending we
can't chain the frames due to unidirectional flow.
SolutionDispatcher gadget
5
JOP Model
Jump Oriented Programming consists of three parts:
1>Dispatcher Gadget: Responsible for control flow
2>Gadget table: is used to hold gadget address and data.
3>Gadget Catalog: the exact instructions matching each gadget which is in
dispatch table
ROP refashioning to make it JOP:
1>stack ptr(esp)  register pointing to dispatch table=>Serves as PC
6
JOP Model
7
Dispatcher gadget
The dispatcher gadget is a specific gadget which plays a critical role in the
JOP technique.It essentially maintains a virtual program counter(pc) and
executes the JOP attack program by advancing it through one gadget after
another.
How do we decide which gadget should be the dispatcher gadget?
8
Dispatcher gadget
We consider any jump-oriented gadget that carries out the following algorithm as
a dispatcher candidate.
pc f(pc);
goto *pc;
pc can be a memory address or register that represents a pointer into
jump-oriented program
Each time the dispatcher gadget is invoked, the pc will be advanced accordingly.
Then the dispatcher dereferences it and jumps to the resulting address
9
Jump Oriented Programming
10
Functional Gadgets
1>The dispatcher gadget itself does not perform any actual work on its
own|it exists solely to launch other gadgets, which are functional gadgets.
2>To maintain control of the execution, all functional gadgets executed by
the dispatcher must conclude by jumping back to it, so that the next gadget
can be launched
Varieties of functional gadgets:
A>Loading data B>Memory access C>Arithmetic and logic D>Branching
E>System calls
11
Gadget Discovery
1. Naïve method=>Disassemble and search for indirect
jumps
Issue=>Instructions are of different lengths
So decoding from one offset may result in different O/Ps
2. SolutionUse Algo of Shacham[5] in context of ROP
A>Find Gadgets(C)
a>Search 0xff which denotes indirect jmps followed by
specific range of values.
b>Use linear search for it.
c>Move backward by 𝛿max which is maximum size of
gadget in byte. Depends on avg instruction size on
architecture
12
Gadget Discovery
Reasons for elimination of potential Gadgets in IsviableGadget(G)
1. Seq that was originally considered to be an indirect jump is no longer
interpreted as such.
2. The post jmp sequence for address may be invalid or writable location at run
time.
3.If any part of gadget doesnot encode x86 instruction
4. If conditional branch in gadget lies outside the gadget bound.
13
Gadget Discovery
The set is further reduced by Heuristic(G)
Because each gadget must end with a jump back to the dispatcher, care must be
taken to ensure that the register used for this purpose is set properly before it is
needed
To locate potential dispatcher gadgets within the codebase, we developed the
dispatcher heuristic
Eg> The instruction must have the jump target as its destination operand. If the
gadget is not modifying the jump target, then it cannot be a dispatcher.
14
Limitations
Though JOP is capable of arbitrary computation in theory, constructing
the attack code manually is more complex.
Two features of the x86 conspire to make gadgets based on jmp and call
especially plentiful. We need to consider what if we apply JOP in an
alternative platform.(e.g., MIPS).
15
Discussions
Find new Heuristics for functional gadgets
Improve efficiency by trying to skip dispatcher gadgets.
16
Conclusion
1.To expand the taxonomy of code-reuse attacks on the x86 to include a new class
of attack: jump-oriented programming. When compared to existing return-oriented
programming, our attack has the benefit in not relying on the stack for control flow.
Instead, we introduce the notion of a dispatcher gadget to take the role of
executing functional gadgets
2. We present a heuristic-based algorithm to effectively discover a variety of jumporiented gadgets on the x86, including the critical dispatcher gadget. Our results
indicate that all of these gadgets are abundantly available in GNU libc that is
dynamically linked to almost all UNIX applications
17
References
[1] L. Davi, A.-R. Sadeghi, and M. Winandy. Dynamic Integrity Measurement and Attestation:
Towards Defense against Return-oriented Programming Attacks. In 2009 ACM STC.
[2] P. Chen, H. Xiao, X. Shen, X. Yin, B. Mao, and L. Xie. Drop: Detecting return-oriented
programming malicious code. In 5th ACM ICISS, 2009.
[3] E. Buchanan, R. Roemer, H. Shacham, and S. Savage. When Good Instructions Go Bad:
Generalizing Return-Oriented Programming to RISC. In 15th ACM CCS, pages 27–38, New
York, NY, USA, 2008. ACM.
[4] S. Checkoway, A. J. Feldman, B. Kantor, J. A. Halderman, E. W. Felten, , and H. Shacham.
Can DREs provide long-lasting security? The case of return-oriented programming and the
AVC Advantage. In EVT/WOTE 2009, USENIX, 2009.
[5] H. Shacham. The Geometry of Innocent Flesh on the Bone: Return-into-libc without
Function Calls (on the x86). In 14th ACM CCS, 2007
18
19