1. Jump-Oriented Programming
Seminar Course : Code Reuse attacks and defenses against them(IN2107)
Jump-Oriented Programming
Name:Urdhwa Golwalker
Matrikel-Nr:

2. Introduction History of code reuse attacks…. Code Injection attacks
Return into libc technique
ROP attacks=> Overwrites stacks
Defense against ROP:
-DynIMA[1].
-DROP[2]
-Return-less approach =>Eliminate all return instructions

3. 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…

4. 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.

5. 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

6. 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

7. JOP Model

8. 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?

9. 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

10. Jump Oriented Programming

11. 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

12. Gadget Discovery
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

13. 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.

14. 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.

15. 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).

16. Discussions
Find new Heuristics for functional gadgets Improve efficiency by trying to skip dispatcher gadgets.

17. 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 jump- oriented 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

18. 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, [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, 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, [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

19. Thank you