When it is time to scan a program for vulnerabilities or just exploit them under GNU / Linux, there are two simple protections that you should keep in mind when it comes to systems with Kernels version 2.6 and higher , and over all if compiled with GCC. There are more protections such as the patch grsecurity or exec-shield (of which I may speak later), even there is protection from hardware called StackGuard .

Virtual Address Space Randomization

The first protection is the creation of random virtual address space in the process , which change with each invocation of the process. By changing this, exploits created for absolute addresses (bone, constants) would be obsolete since they change the addresses with each execution of the program and its libraries in a range of 8MB. This applies only to ELF (Executable and Linkable Format) binaries .

The method to enable and disable it is simple, I will demonstrate the change of addresses in memory with the following code:

This code would give me the exact address of ESP at the time of execution. Now with this code we are going to test the protection in itself of the kernel in question. The system file that controls this option is located in / proc / sys / kernel / randomizevaspace (only manipulated by a superuser or root ) and we could say that it is controlled by a TRUE (1) or FALSE (0). Then, let's try:

By enabling this "patch" we can see that the addresses are changing and making it almost impossible to know the virtual address of ESP (in this case ..) until the moment of execution. Now let's disable this function and let's see what happens:

After disabling the patch we can see that the address of ESP is constant in the executable, without even recompiling it!

But do not be frightened, as history has taught us! Behind every security system is someone trying to break it .. 1

GCC StackGuard (ProPolice) Protection

Well, this is a security protection implemented in the ultra renoted compiler and found in every GNU / Linux distribution, I speak of GCC (GNU Compiler Collection) . This compiler comes with a protection system called "StackGuard" developed by Immunix and now called ProPolice 2. This protection detects a buffer overflow attack (always on the stack) by creating a value called "Canary" between the created buffers and the frame pointer (EBP) & "return address" (EIP), then when a buffer attempts overwriting these values ??must in one way or another overwrite the value "Canary" and this serves as a trigger for protection that gives an alert and takes action against it, for example, stopping the process.

Well, let's see how it reacts to a simple overflow like this:Code: C ++#include <stdio.h>#include <string.h>

As we see, there is a 32-byte buffer and not a single check when doing the string copy to the buffer. We already know that we have 32 bytes of buffer + EBP + EIP, but if the protection is enabled we would not allow or pass the frame pointer:

As shown stops the program in - instructional leave that (so I understand) is responsible for moving ( mov ) to% ebp to% esp and remove ( pop ) to% ebp stack, that would mean intends to return to ESP and with the copied buffer ( call 0x8048320 <strcpy @ plt> ). It is there where the canary is overwritten and the entire procedure is stopped after the check. The check is done using the _stackchkfail () function .

Now let's try the program sin this protection. For that we are going to compile the program with the flag --no-stack-protector :

And without this protection we were able to overwrite EBP and EIP without any difficulty, which would be easy to exploit even more if the protection of which you speak before is disabled to be able to get the constant address of ESP and overwrite the process flow. In itself, I only talk about a single method of protection of this extension, which for what I know are 5.