ret2libc - why need 4 bytes of garbage

Question

So I started to learn reverse engineering, and I came across the ret2libc exploit.

I tried to understand how it works and I got a bit confused.

They say that when you return to the address of system you then need to give 4 bytes of garbage and the after that give the address of /bin/sh.

Why do you need to give these 4 bytes of garbage and can't just jump to system and from there to /bin/sh?

ROP attacks rely on proper alignment of the injected addresses (pointing to libc gadgets) in the stack. These 4 bytes are probably just buffer bytes used to align the address correctly, but this can change depending on the system architecture and even how the stack is laid out (where the return address you are trying to overwrite lies). It's hard to say when your question does not contain any links to whatever article you were reading, or any example of how the target program is set up. Can you clarify on these points? Where did you read about ret2libc? — ExecutionByFork, Dec 05 '19 at 20:25
i read the article in this site: https://0x00sec.org/t/exploiting-techniques-000-ret2libc/1833. — DaniDin, Dec 05 '19 at 20:37

score 1 · Accepted Answer · answered Dec 06 '19 at 07:20

Let's say we're exploiting buffer overflow in some foo function. Consider the following stack after overflowing the buffer, stopping at ret instruction in foo function:

   ....
------------------------
"system" fn address         <-- stack pointer
------------------------
4 bytes of garbage
------------------------
"bin/sh" address
------------------------
   ...

After that, when we execute ret instruction, we'll jump right to the system function. Then, stack will look like this:

   ....
------------------------
4 bytes of garbage          <-- stack pointer
------------------------
"bin/sh" address
------------------------
   ...

so, now we are in system function. Those 4 bytes of garbage are now the return address for system function, and the values below return address are system function arguments – in our case it's single *char argument that points to "/bin/sh" string.

wireghoul · Answer 2 · 2019-12-06T05:08:32.000

0

It's likely the intended return address, garbage will cause a segfault. For a more detailed explanation see my answer to Why must a ret2libc attack follow the order "system(),exit(),command?

edited Dec 06 '19 at 05:08

answered Dec 05 '19 at 20:45

wireghoul

5,745
2
17
26

score 0 · Answer 3 · edited Dec 16 '19 at 11:15

Ret2Lib is a type of attack that overwrites the Return address of a vulnerable function with a different address, usually of a function that already exists in the process executable memory. This feature is used to bypass the non-executable stack that prevents attackers from writing code. It is generally started with a BOF of a vulnerable function which allows an attacker to rewrite the Return Address of the function with a different address. This is usually done with the system command as it allows the attacker to gain the most access to the system by spawning a shell. If we look at the structure of the call stack we can see that the order in which data is stored onto the stack is:

The arguments
Return Address
Parameters

Here is where the garbage data comes, as the system call requires no Arguments to be passed to it There needs to be a return address that is must be specified before we can enter the Parameters which usually are '/bin/sh' . As we do not care about the exiting of this function we can enter any garbage values in here it would not matter but the position of the Parameters needs to carefully calculated when writing an exploit.

However in real-world binaries it usually exited with the exit() or returned to its original execution state to not arouse any suspicion or leave any traces of the exploit, we usually see the return address of the exit command or of the original function entered here instead of some garbage values.

ret2libc - why need 4 bytes of garbage

3 Answers3