I am not sure this is a right place to ask this question or not.

I want to know in previous or modern type of buffer overflow attack, when the attacker succeeded to overwrite return address, where he/she set the new return address to point to? As we know today because of new protection mechanisms it's harder to insert code and execute it (Data Execution Prevention), therefor attacker try to use address of existing code/library like "libc" to change control flow to them. I wonder beside "libc" what opportunity exist that can be used by them?

  • 1
    Read about ROP (return-oriented programming) attacks that are extension of return-to-libc ones. Basically, whatever known pre-loaded code provides enough opportunities to construct ROP sequence. (And yes, libc is not in kernel, so technically the question is not correct, although still can be answered.)
    – Van Jone
    Jun 14, 2013 at 2:27
  • @VanJone I read about ROP but I have problem with their approach , because for each gadjet they need to use some kind of buffer-overflow that is impossible in new system.
    – Am1rr3zA
    Jun 14, 2013 at 16:20
  • Then can you be more specific about particular "new system" protection techniques? You asked about only sole NX protection that can be beaten purely by ROP. If you mean some other additional protection (say, ASLR) then it's a different matter how to deal with it too to let ROP work. As ASLR doesn't blindly apply to all libs and even not to all exec-s sections, then the way to beat NX+ASLR will become very versions-specific.
    – Van Jone
    Jun 14, 2013 at 16:48
  • @VanJone I really don't care about protection, I want know beside libc what library can be used by attacker to jump to? I am not sure I can make myself understood or not.
    – Am1rr3zA
    Jun 14, 2013 at 21:58

1 Answer 1


Update: You seem to be expecting more concrete information, so I expanded my post a bit. As far as I know, however, no code besides the actual program, libraries and kernel code is usually mapped to memory when your program is run in user mode.

There are several places you could redirect the control flow to, in case the stack is not executable:

  • ret2data: Place the exploit code into the data section and then point the return address there. Often not possible.
  • ret2text: Jump to existing code in the .text section of the exploited binary. This includes jumping to DLLs and other shared libraries (and theoretically even kernel code, without a mode switch).
  • chained returns: A technique that can be used to combine several methods. Basically, you prepare the stack so that the returning instruction of the first function will jump to the second function, and so on.
  • partial returns: Another technique. You don't have to jump to the beginning of a function, but can also jump in the middle or near the end.
  • ret2syscall: A practical example what you can do. Basically, you have an int 0x80 instruction (a linux system call that expects its arguments in registers) and any function that cleans up the stack, for instance pop eax; pop ecx; pop edx; pop ebx; ret; You fill the stack with the address of the pop eax instruction, then the values of the registers and then the address of the syscall.
  • do you have any references for what you said?
    – Am1rr3zA
    Jun 21, 2013 at 20:51
  • @Am1rr3zA You can read up most of what I said in Shellcoder's Handbook
    – copy
    Jun 21, 2013 at 21:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .