Browse Prior Art Database

ROP Prevention Using Encrypting Return Addresses

IP.com Disclosure Number: IPCOM000246196D
Publication Date: 2016-May-16
Document File: 5 page(s) / 40K

Publishing Venue

The IP.com Prior Art Database

Abstract

A ROP attack relies on the 'return address on stack architectures' where the control flow of an application can be rerouted by changing the return addresses on the stack. When the execution of a callee procedure is done, a return instruction is executed and the return address is fetched from the stack to return to the caller. Thus, changing the return addresses on the stack enables the attacker to perform ROP attacks. Preventing attackers from using return addresses as a technique to reroute the control flow of an application is possible if the attacker is prevented from writing to the stack, where we achieve that by writing encrypted addresses with private key instead of saving plan address values to the stack.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 41% of the total text.

Page 01 of 5

ROP Prevention Using Encrypting Return Addresses

One of the modern severe software attacks is returned-oriented programming (ROP) where an attacker takes control of a program flow, by smashing the call stack, to execute instruction sequences. Security researchers report that ROP attacks are found in almost every attack chain based on exploits. ROP technique is used to overcome data execution prevention, DEP, defense technique, which was developed to prevent shellcode injection and execution. DEP technology was presented as a solution which prevents most buffer overflow exploits, and inject and execute code. DEP technology forces the attackers to move to other hijacking techniques as ROP attacks in order to achieve their goals.In ROP technique, the attacker borrows gadgets (small pieces of code) from the hijacked program to execute the malicious code. The attacker performs this by smashing the stack and overwriting it with values that diverse the instruction pointer return address to the attackers' gadgets. The gadgets combined functionality is equivalent to the attacker malicious shellcode. In ROP attacks, the attacker reuses chunks of code that exists in available shared library function (for instance, kernel32.dll, user32.dll, etc), where these chunks end with a return instruction and perform needed functionality. The entire process of looking for these chunks is easy and there are many free tools that build the values that are to be injected to the stack:

- http://cseweb.ucsd.edu/~hovav/papers/s07.html

- http://users.ece.cmu.edu/~ejschwar/papers/usenix11.pdf

- https://github.com/pakt/ropc

Previous Work

Many techniques and tools were developed to prevent ROP attacks and other permutations of it .

These techniques have been defeated, either because the attacker bypasses it, or because they affect the user experience, by requiring high overhead of performance, etc.:

1


Page 02 of 5

We introduce here the main techniques:

- Address space layout randomization (ASLR), this technique is used against buffer overflow and ROP attacks. The idea is to rearrange the address space such that it will be difficult for the attacker to know the address of the targeted gadgets. In this technique, the code of the shared library is relocated in different memory space, namely, the code starts in different space address. In ROP attack the space memory layout is important to the attacker in order to know where the gadgets are located. Many attacks where developed again ASLR, where the attacker tries to guess the location of the code, or by using some attacks that leak the memory layout such as format string vulnerabilities that enable the attacker to know the location of the code . http://benpfaff.org/papers/asrandom.pdf

 Currently, ASLR is embedded in many operating systems - Windows, Linux, Android, etc. and hardware solutions however, it is bypassed and it is not a sufficient solution.

- Instruction Location Randomization (ILR), this technique randomi...