Difference between the Ret2Libc and ROP attacks

[preetd14]

Hi!

I noticed that the return-to-libc and ROP attacks in the code do almost the same thing. They call an unreachable function by overflowing a target address with the address of the ret2libc_target() and rop_target(). The only difference is during the payload.overflow_pointer initialization:

case RETURN_INTO_LIBC:
    // JM: simulate ret2libc by invoking mock libc function
    payload.overflow_ptr = &ret2libc_target;
    break;
case RETURN_ORIENTED_PROGRAMMING:
    // skip over the prologue code of rop_target
    // to simulate return-oriented programming gadget
    payload.overflow_ptr = (uintptr_t) &rop_target + 16;
break;

I wanted to know why the overflow_ptr for ROP has a type conversion to uintptr_t and an offset of 16 bytes when in fact both the target functions are of void type and print similar messages when executed. Even the payload building process is the same for both these attacks (just copying the overflow_ptr value at the end of the payload to overflow the target address).

The reason I want to know this is that I am using a RISCV port of gem5 to execute this benchmark and ROP always fails while return-to-libc is mostly successful. Here are the gem5 simulation outputs of similar rop and ret2libc configurations:

RIPE configuration: -t direct -l stack -c funcptrstackvar -i rop -f memcpy -d
gem5 output:

**** REAL SIMULATION ****
info: Entering event queue @ 0.  Starting simulation...
tech: 100
location: 400
code ptr: 301
attack: 202
function: 500
debug info enabled
----------------
Shellcode instructions:
lui t1,  0x00011                     00011337
addi t1, t1, 0x47a                   47a30313
jalr t1                              000300e7
----------------
target_addr == 0x7ffffffffffffc38
buffer == 0x7ffffffffffff800
payload size == 1089
bytes to pad: 1080

overflow_ptr: 0x11526
payload: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA&

panic: panic condition !handled occurred: Page table fault when accessing virtual address 0
Memory Usage: 8495668 KBytes
Program aborted at tick 40075500

RIPE configuration: -t direct -l stack -c funcptrstackvar -i returnintolibc -f memcpy -d
Output:

**** REAL SIMULATION ****
info: Entering event queue @ 0.  Starting simulation...
tech: 100
location: 400
code ptr: 301
attack: 201
function: 500
debug info enabled
----------------
Shellcode instructions:
lui t1,  0x00011                     00011337
addi t1, t1, 0x47a                   47a30313
jalr t1                              000300e7
----------------
target_addr == 0x7ffffffffffffc28
buffer == 0x7ffffffffffff7f0
payload size == 1089
bytes to pad: 1080

overflow_ptr: 0x11494
payload: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA�

Executing attack... success.
Ret2Libc function reached.
Exiting @ tick 42464500 because exiting with last active thread context

The one interesting difference in the two outputs I noticed was the different target address and buffer address values for the same location and target code pointer (which does not make sense because they remain the same between shellcode and returnintolibc):

ROP and Shellcode (for location-stack and target code pointer-funcptrstackvar):

target_addr == 0x7ffffffffffffc38
buffer == 0x7ffffffffffff800

Return-into-Libc (for location--stack and target code pointer--funcptrstackvar):

target_addr == 0x7ffffffffffffc28
buffer == 0x7ffffffffffff7f0

Can someone please help me understand why this is happening and if it is related to the difference in how their overflow pointers are initialized?