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?

Answer 1

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.

Answer 2

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?

Answer 3

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.