|Home » Learning Curve » Can't Take a Punch
Microsoft's Remedies: Heap Protection
Protecting that glass jaw.
If programs allocate memory and if this memory can be overwritten by rogue processes with data of their own and if the rogue processes can get the target programs to turn over control to these memory areas - then the program can be hacked.
The legacy exploitation technique is to overwrite the header of a heap to create a fake free memory block on the heap under control of the hacker. The manipulation of heap control data can lead to hackers being able to write four bytes of data to an address anywhere in memory - which can lead to rogue code taking over. Microsoft have therefore implemented a number of techniques to thwart this attack.
Safe unlinking is used when removing memory from the so called 'free list'. The code will first make sure its control data is correct.
Heap Metadata Cookies and Encryption
A single byte cookie is stored in the header of each heap chunk. The cookie is checked when the chunk is removed from the 'free list'. If hackers overwrote the heap then the cookie won't match and the program will abort.
A later technique is to use heap metadata encryption instead: all important fields in the heap's header are XORed with a random 32-bit value (and of course decrypted before being used).
So the heap's safe now? And how about executing code in areas not meant for code?