lesson_09.md 2.0 KB
Computer Security - lesson 9
Stefano Zanero
21 April 2016
Preparing the Memory
To effectively use the buffer overflow we need to create the exploit buffer and put it in memory using a helper program, the exploit buffer will include half size of nops, and following the shellcode and the ESP.
We may want to have more than one repetition of the ESP because if the program
we are attacking is distributed already compiled, we can be precise
but if it has been compiled ad-hoc, then it may have offsets.
A clever script prepares the buffer and loads it into an environment variable EGG
before starting a terminal, then i can ./executable <echo $EGG` and pass the buffer
that i couldn't have written by keyboard.
We can make a more effective shellcode making it tinier, with the same techniques
that were used in the demo-scene.
We can alternatively use the saved EIP of a function pointer if that function is accessible
by our buffer and run before the exploit.
One of the most common programming error is the off-by-one made by counting arrays
starting from 1 instead of 0.
Defense from buffer overflows
The main cause are programming errors
Source code level defense
Use safer librearies, es:
strncopychecks for input size.Compiler level defenses
Compilers can notify about source code mistakes
Randomly allocation of variables on the stack
Use of a canary that is a sacrificable piece of code, that is checked to make sure the buffer was not exploited (Reference from canaries used by miners) Static canaries can be easily replaced, there are more effective tecniques like Terminator canaries (made of
\0) and Random canaries If we seek performance we may disable canaries by NOT using-fstack-protectorBuf for normal programs it should stay enabled.Operating System level:
- Non executable stack, e.g. NX bit that make the program crash if jump into a section of memory with NX enabled
- Address Layout Randomization; for example in linux the stack is shifted in a 2MB range every execution.