Exploitation Protections From Old To Bleeding Edge pt 2
Hey again, here’s the second part of the three parts article about the protections that were developed to mitigate or even hinder the process of exploitation.
If you came by without reading the first part, here’s the link: https://medium.com/stolabs/exploitation-protections-from-old-to-bleeding-edge-pt-1-7fd0c9caab60
In this article, the main objective is to get through most of the compile-time controls , that is, the ones that (obviously) are defined as the protections that are added during compile time.
The two main points that are important about compile time controls that differ from the OS controls:
Not mandatory (not system enforced)
Inserts code or metadata
Compile Time Controls
SafeSEH
The exploit dev study path starts with the vanilla buffer overflows with the eip overwrite all those good black magic stuff. The next step in the process is the SEH based exploit, the one that introduces concepts like stack pivot, SEH chain overwrite, and the famous EB instruction (JMP short).
And this protection sought to mitigate this kind of problem, i will not get deep into what SEH means, but you can read a bit about this here: https://docs.microsoft.com/en-us/windows/win32/debug/structured-exception-handling. Very basic stuff.
The SafeSEH is a compile-time control that saves a table containing all addresses of the valid handlers within a DLL. With this kind of protection, techniques like the famous POP POP RET that targets a DLL with the SafeSEH module wouldn’t work, the process gets terminated with an error message.
This protection isn’t very solid seeing that ALL the DLLs loaded into the process must have this control, if one single module does not participate in the control will render this protection to be ineffective.
Stack Canaries or security cookies.
This control is simple to understand and is just a special value that lies above the return pointer of a function for protection.
This alone would stop stack smashing attacks, because you cannot simply guess a 64bit value to make the return process valid. And if the value is not passed, the process simply terminates with an error
But just as the protections evolve, the attacks evolve too, said that, two techniques are used to bypass this control:
Stack canary leaking — Involves format string bugs to leak the value
Bruteforcing canary — Involves some bruteforcing witchcraft
About the Canary : https://pt.wikipedia.org/wiki/Stack_canary
About the bypasses: https://ctf101.org/binary-exploitation/stack-canaries/#:~:text=Stack%20Canaries%20are%20a%20secret,modified%2C%20the%20program%20exits%20immeadiately.
LFH or Low Fragmentation Heap
This is a really old protection implemented at windows XP SP 2/3 and Win Server 2003, and I don’t see a lot of people that talks about this one, maybe because not everyone used it, as it was only active if it was explicitly configured and compiled to run with an application. But it got some attention post-WinXP
This mitigation is a very hard barrier to the heap it manages. the core of the protection lies at 32-bit XOR encoding the heap allocated chunks.
It can be used in blocks up to 16kb and it allocates the blocks in predetermined size ranges by putting those blocks into buckets.
Read more about LFH: https://docs.microsoft.com/en-us/windows/win32/memory/low-fragmentation-heap
MemGC (and a bit about MemProtect)
Memory Garbage Collector is a replacement of the MemProtect introduced in Windows 10.
Hardcore protection, aimed at protecting against UAF (Use After Free) attacks. the old MemProtect only searched in the stack for the references prior to freeing. MemGC checks any MemGC-managed chunks for objects marked to be freed. And obviously if that object marked to be freed still has a reference, that will cause an exception.
A bit more: https://securityintelligence.com/memgc-use-after-free-exploit-mitigation-in-edge-and-ie-on-windows-10/
Some Other Minor Compile Time Protections
Range Checks
Is a compiler Security Check that when a variable is set it is checked if that variable is within a bound that is not always done as this is time consuming. Some compilers even have the feature of eliminating this kind of verification.
Read more (not much to be read to be completely honest): https://en.wikipedia.org/wiki/Bounds_checking
Sealed Optimization
This one forces the C++ virtual functions into direct calls removing the requirement of the problematic indirect calls.
Those indirect calls were often abused by the use of class-based exploitation techniques, where an application relies on a call to a register-based offset.
Virtual Table Guard or simply VTG
It adds an If block to the code to help protect the class-based VPTR by adding a guard at a known offset. If the VPTR is overwritten, when the guard is checked, the process is terminated with an exception.
Read more : https://eyalitkin.files.wordpress.com/2017/01/liberation-guard-eyal-itkin.pdf
Guard Pages
The GP protection adds to help the heap to protect the dynamic memory. If an attacker performs and hits a guarded page protecting heap allocations, an exception will be sent to terminate the process.
Read more:https://docs.microsoft.com/en-us/windows/win32/memory/creating-guard-pages
The third and last part of this article will come in the next week! cya
