In my last article I provided a practical exhibition and explanation on runtime process infection using a technique commonly referred to as PLT/GOT redirection or GOT poisoning. This particular infection technique is relatively easy to execute and has been known by the public since the early 2000's. Following on from the previous article, I wanted to explore and talk about the possible mitigation techniques that can be employed to either erradicate or increase the overall complexity of performing such memory corruption.
Considering overflow exploits that effect structures within the data segment have been well known for such a long time, surely there has been something done to address this issue. In fact, there is something. One of the mitigation techniques that an ELF can implement is known as RELRO, which I intend to cover thoroughly within this article.
Some of you may be asking yourself questions like What exactly is RELRO? What does it stand for? Why use it? How does it work? How can I check whether an binary type of ELF has been compiled using RELRO? etc. These are all completely valid questions, and not so long ago I was asking myself the exact same things.
RELRO is the abbreviation used for the term RELocation Read-Only. It is a command-line switch that is provided to the linker program during the linking phase of the compilation process. It requests the linker program to segregate and position particular sections within the ELF file being compiled in a alternative manner so that additional memory protection mechanisms may be enforced by the dynamic linker. The concept of restructuring the layout of the data section within ELF dynamic shared objects and executables to mitigate data section buffer overflows appears to have come from a patch introduced in 2004[1].
Be patient, the rest of this article is coming...