|Home » Learning Curve » Can't Take a Punch
Kicking systems with glass jaws.
A recent paper by Alexander Sotirov and Mark Dowd of IBM attempts to highlight the efforts Microsoft have made in recent years to beef up their system security.
The paper was presented at Black Hat 2008. It was facetiously called 'Impressing Girls with Memory Protection Bypasses'. But the authors are highly respected researchers and they weren't joking.
Sotirov and Dowd studied five separate techniques Microsoft have implemented to strengthen their periphery and found flaws in them all. They end their paper on a hopeful note, encouraging Microsoft to fix things for the next release. But it's a hopelessly naive sentiment.
The ambition of the article you're reading now is to present the findings of Sotirov and Dowd in such a way even laypersons can understand (albeit at times with a bit of difficulty). This article follows the structure of the Sotirov/Dowd paper and finally add comments of its own.
Sotirov and Dowd only worry about hacks: attempts to corrupt running processes. Other techniques that have flourished on Windows such as the Love Bug and AnnaK have little to do with hacking in the same sense: they're mostly a matter of social engineering. A recurring (and nagging) realisation with use of Windows has always been that once enemy code is inside the perimeter the game is basically over - Windows can't take a punch.
Given that inner security on Windows is so weak (or nonexistent) it becomes crucial to hold the outer perimeter - to not let rogue code into the system. Rogue code will normally get in by supplying deliberately flawed data to processes already running. This data will not be handled correctly by the processes and will overwrite parts of their memory, causing them to behave in the fashion the hackers want rather than the way they were supposed to work.
Sotirov and Dowd isolate five areas of memory protection Microsoft came up with for their most recent versions of Windows.
- The stack. Remedies: stack cookies and the 'strict_gs_check' pragma, stack variable reordering.
- Exception handling. Remedy: chain and handler validation.
- The heap. Remedies: protecting allocated memory itself and how the process uses it, safe unlinking, safe lookaside lists, heap metadata cookies, heap metadata encryption.
- Data sections. Remedy: data execution prevention (DEP). Includes support for Intel's NX, permanent DEP, and OptOut mode by default.
- Address space layout. Remedy: address space layout randomisation (ASLR). Includes randomising PEB and TEB (process and thread) structures as well as heap, stack, and image randomisation.
The theory - because that's all it is - is that if you can cut off all possible means of attacking running processes then you can reduce the number of exploits to zero.
Techniques to protect the above areas have been gradually incorporated into current versions of Windows.
So how much did Microsoft do? And more importantly: did it really help?