Hacker's Diary "V" - Arc Injection

The  exploit for a get password program modifies the return address to change the control flow of the program (in this case, to circumvent the password protection logic). This technique, which is known as arc injection (sometimes referred to as return-into-libc), involves transferring control to code that already exists in the program's memory space. Arc injection refers to how these exploits insert a new arc (control-flow transfer) into the program's control-flow graph as opposed to injecting code. More sophisticated attacks are possible using this technique, including installing the address of an existing function (such as system() or exec(), which can be used to execute commands and other programs already on the local system) on the stack along with the appropriate arguments. When the return address is popped off the stack (by the ret or iret instruction in IA-32), control is "returned" to an attacker-specified function. By invoking functions like system() or exec(), an attacker could easily create a shell on the compromised machine with the permissions of the compromised program.
Worse yet, an attacker can use arc injection to invoke multiple functions in sequence with arguments that are also supplied by the attacker. An attacker can now install and run the equivalent of a small program that includes chained functions, increasing the severity of these attacks.
 Program that is vulnerable to a buffer overflow is shown below. User-supplied data in user_input is copied to the buff character array on line 4 using memcpy().A buffer overflow can result if user_input is larger than the

 1. #include <string.h>
 
 2. int get_buff(char *user_input){
 3.   char buff[4];

 4.   memcpy(buff, user_input, sizeof(user_input));
 5.   return 0;
 6. }

 7. int main(int argc, char *argv[]){
 8. get_buff(argv[1]);
 9. return 0; 
10. }

 
buff buffer. Figure 1 (a) shows the contents of the stack before execution of the get_buff() function. The stack consists of the local variable buff, followed by the frame pointer (ebp) and return address (eip) for main(). Below this is the actual stack frame for main() (which is referenced by the stored frame pointer).
Figure 1 (b) shows the contents of the stack after an attacker has overflowed buff to overwrite the contents of the stack. This portion of the stack has been completely overwritten by the overflow.
An attacker may be able to place data in the actual buffer, but in this example we'll assume that the buffer is overwritten with fill characters. The frame pointer for main() has been overwritten with a frame pointer for Frame 2. This entire frame has been manufactured by the attacker as part of the exploit. When the exploited function (get_buff()) returns, it executes one of two equivalent forms of the frame pointer-based return sequences shown in Figure 1 (c). Regardless of which form is used, the frame pointer (now pointing to Frame 2) is moved into the stack pointer. Control is returned to the address on the stack, which has been overwritten with the address of an arbitrary function f(). This function is called and passed the arguments installed on the stack. The attacker must provide the appropriate number and type of arguments assumed by the invoked function. In Figure 1 (b), we assume that the function accepts a pointer to a string (for example, "system()"). Because the actual contents of the string also need to be provided, the string is placed on the stack after the actual arguments to the function.

Figure 1

When f() returns, it pops the stored eip off the stack and transfers control to this address. In this case, the eip has been overwritten with the address of the return sequence shown in Figure 1 (c). This sequence is usually the instructions generated for the return to the exploited function, but it can appear anywhere in the code segment for the process. The return sequence assigns the frame pointer (now pointing to Frame 3) to the stack pointer and returns control to the the next arbitrary function to be called (in this case, g()).
An attacker can repeat this sequence as required to invoke a sequence of functions to accomplish an exploit. The attacker could also reproduce the original frame contents on the stack to return control to main() after the exploit has executed.
An attacker may prefer arc injection over code injection for several reasons. Because arc injection uses code already in memory on the target system, the attacker merely needs to provide the addresses of the functions and arguments for a successful attack. The footprint for this type of attack can be significantly smaller and may be used to exploit vulnerabilities that cannot be exploited by the code injection technique. Arc injection is a data-based attack that cannot be defeated by making memory segments (such as the stack) nonexecutable.
Chaining function calls together allows for more powerful attacks. A security-conscious programmer, for example, might follow the principle of least privilege  and drop privileges when not required. By chaining multiple function calls together, an exploit could regain privileges, for example, by calling setuid() before calling system().