Linux Exploit Development Part 3 - ret2libc.pdf

(552 KB) Pobierz
Linux exploit development part 3 - ret2libc
NOTE: In case you have missed part 1 and 2 you can check them out here:
Linux exploit writing tutorial part 1 - Stack overflow.pdf
Linux Exploit Writing Tutorial Pt 2 - Stack Overflow ASLR bypass Using ret2reg.pdf
If you remember from part 2, when compiling the vulnerable app we have used the flag -
z execstack with gcc which gives us an executable stack, but in these days most operating
systems use by default non-exec stacks.
Also our previous exploits were made on Backtrack 4 R2, this time we are going to make the
exploit in a Debian Squeeze.
Required knowledge:
- Understanding concept behind buffer overflows
- ASM and C/C++ knowledge
- General terms used in exploit writing
- GDB knowledge
- Exploiting techniques
If you continue reading this paper without possessing the required knowledge I can not
guarantee that it will be beneficial for you.
Author: sickness
Blog:
http://sickness.tor.hu
Date: 06.04.2011
What are non-exec stacks?
In general, the non-exec prevents some stack (or heap) memory areas from being executed. It
also may prevent the executable memory from being writable, which could prevent some buffer
overflows from working. An example of this would be a buffer overflow where you inject and
execute code.
For more information about the non-exec you can take a look over
here.
Since we can not inject nor execute our code, what do we do now? To bypass this protection
feature, we will
use a technique called “ret2libc” (Return to libc).
How does it work?
As you have probably guessed by now, libc will be very helpful in this technique, but why
exactly?
The overflows you have seen in my previous tutorial have the following structure:
##############################
JUNK + NOP sled + SC (Shell code) + EIP (overwrite with a JMP/CALL instruction to a register that
points in our JUNK/NOP sled)
##############################
This will not work now because of the non-exec stack. A jmp on the stack will result in
a segfault. Here is where libc comes in: instead of overwriting EIP with an instruction, we
actually overwrite EIP with functions from within libc library, followed by the required function
arguments.
NOTE: You can actually make the code return anywhere you want to, libc is just the most
common target because we always find it linked to the program and it provides the most useful
calls.
Author: sickness
Blog:
http://sickness.tor.hu
Date: 06.04.2011
Now that you understand the “big picture”, we are going to take it step by step and
demonstrate this technique.
We have the following vulnerable application:
##############################
#include <stdio.h>
#include <string.h>
void evil(char* input)
{
char buffer[500];
strcpy(buffer, input); // Vulnerable function!
printf("Buffer stored!\n");
printf("Buffer is: %s\n\n",input);
}
int main(int argc, char** argv)
{
evil(argv[1]);
return 0;
}
##############################
In the previous tutorial, we compiled the app with the -z execstack flag in gcc. This time
we will leave it default (noexec).
Figure 1.
Author: sickness
Blog:
http://sickness.tor.hu
Date: 06.04.2011
We quickly attach the vulnerable program to gdb and set breakpoints at “call evil”, and “ret” from
the “evil” function to calculate the needed offset for our payload.
Figure 2.
Figure 3.
Author: sickness
Blog:
http://sickness.tor.hu
Date: 06.04.2011
Now that we have placed our breakpoints, let’s send some junk to the app and see what
happens.
Figure 4.
Figure 5.
Author: sickness
Blog:
http://sickness.tor.hu
Date: 06.04.2011

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika:

Zgłoś jeśli naruszono regulamin