Hello everyone, in last part I have talked about how to write a Shellcode.
Today I will talk about the protection of stack!!
We still will stay on x64 Linux-system. In the part 1, we used to return to the address of system function with Buffer Overflow, or return to the global variable, and overwrite it with the Shellcode. Therefore, some protection of stack appear to fight against the attack. For example, they randomize the address of function to let us not sure where to return, or make the Shellcode we insert into the stack cannot be executed, these are all the way to stop from BOF attack.
Common types of protection will be showed at following:
- Stack Guard
Look at the top of the picture above. ASLR can be separated to 4 levels, 0~4 respectively, and level 0 means the ASLR is closed. When it comes to the use of ASLR, it will make the address of stack, heap, library randomized (with the same offset. Therefore we can see the downside of the picture above: the position of the stack, library, heap have changed since the first run time to the second. I will show the result in the terminal at following picture.
First, we can use command "cat /proc/sys/kernel/randomizevaspace" to show the levels of ASLR. In the picture, it shows with 2, so it means that the ASLR is open. Then we use the "ldd" to see the address of loading library. Taking the libc.so.6 for example in the picture above, we can see the first address of the it is 0x7fc890536000, but when we run it again, it has changed to 0x7f1c41e98000. OK, this is ASLR!
In the picture above, I have use the command "vmmap" to show the memory address of the program. We can see that in every section of memory, it cannot be executed if can be written, or cannot be written if can be executed. This is the characteristic of the DEP, also called as NX.
PIE seems as ASLR, but there is a little difference between. PIE will let the address of .data .code also be randomized with the ASLR. Therefore, if we use the command of "objdump -d elf" to take a look at the elf, which comes with PIE open, we will not see the real address, but the offset in it. And it will add to the base address to become the real address after the program running.
The Last. StackGuard
StackGuard, which is also called Canary, is the most interesting one of the protection. Look at the picture above, and we can realize how the Canary works. First, we need to know that Canary are all stored in a memory section called tls, and there are register fs/gs point to them in x64/x86 respectively. Second, the Canary will take action after function prologue. After the new stack frame is built, stack will insert a pointer to canary and check it value before leave the function. Take the pircture above as example, if we want to overwrite the return address, it should overwrite the canary, too. But we look at the green words at the left side, the green part is the process of checking value of Canary. It will copy the value of canary on the stack to the rax, and compare to the original value which is stored in the fs/gs. If two values are not the same, the program will abort! So this is the mechanism of "StackGuard"!