Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
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 '13 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 '13 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 '13 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 '13 at 21:58

1 Answer 1

up vote 3 down vote accepted

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.
share|improve this answer
    
do you have any references for what you said? –  Am1rr3zA Jun 21 '13 at 20:51
    
@Am1rr3zA You can read up most of what I said in Shellcoder's Handbook –  copy Jun 21 '13 at 21:07

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.