I came across a great paper, “Memory Errors: The Past, the Present, and the Future” by van der Veen et al. The authors cover the history of memory corruption errors as well as exploitation and countermeasures. I think there are a number of interesting conclusions to draw from it.
It seems that the number of flaws in common software is still much too high. Consider what’s required to compromise today’s most hardened consumer platforms, iOS and Chrome. You need a flaw in the default install that is useful and remotely accessible, memory disclosure bug, sandbox bypass (or multiple ones), and often a kernel or other privilege escalation flaw.
Given a sufficiently small trusted computing base, it should be impossible to find this confluence of flaws. We clearly have too large a TCB today since this combination of flaws has been found not once, but multiple times in these hardened products. Other products that haven’t been hardened require even less flaws to compromise, making them more vulnerable even if they have the same rate of bug occurrence.
The paper’s conclusion shows that if you want to prevent exploitation, your priority should be preventing stack, heap, and integer overflows (in that order). Stack overflows are by far still the most commonly exploited class of memory corruption flaws, out of proportion to their prevalence.
We’re clearly not smart enough as a species to stop creating software bugs. It takes a Dan Bernstein to reason accurately about software in bite-sized chunks such as in qmail. It’s important to face this fact and make fundamental changes to process and architecture that will make the next 18 years better than the last.
rdist 
Stacks are an interesting, venerable piece of legacy. For example, having a stack grow downwards was vey useful at the time there was no virtual memory, but it also now makes overwriting return adresses much easier. Why the industry could not move to upwards stack is a bit of a puzzle to me. Also, we keep wanting to mix automatic variables (data pane) and return adresses (control pane) on the same stack. Shouldn’t be too difficult to use two stacks to stop mixing control and data panes here. Would mean a redefinition of the calling conventions, but this can easily be done when introducing new platforms.
Whatever exploitation technique is used, at some point the attacker wants to execute arbitrary code. A good mitigation is to only allow execution of signed code. iOS chose that road and almost succeeded. The failure? The OS is allowed to turn that mechanism off, for whatever reason. This is a perfect illustration of the too-big TCB. Actually, a way to see it is that you need different levels of trusts, and the most-trusted component should be a mechanism whose sole purpose is to make sure only signed code is allowed execution as a given privilege, also managing trust chains.
In conclusion, with all defenses we have now (NX, ASLR…) we are really hacking around the issues instead of fixing the core problems in the architecture. Granted, easier said than done :)
@secolive
Easy solution: Use memory-safe languages so that we don’t have exploits from bugs. This doesn’t solve all security problems, like Confused Deputies, but does solve most of them. Ada, Java, SML, etc. are all much safer then C, and in many cases just as fast.
A couple of (late) comments on the comments:
1) stack direction will not solve the problem. Often buffer overflows happen not in the function containing the buffer but in one of the called functions. There will be a return address somewhere in memory after the buffer no matter which direction the stack grows in.
2) Code signing does nothing to prevent arbitrary code execution post-exploitation. An attacker can dynamically generate and execute code as needed once control flow has been hijacked. Check out some of the small interpreters available in professional exploit kits such as Core Impact or Metasploit Framework, for example.
3) This blog would indeed be a great platform for telling the world about your company’s new contest and about male virility!