Is buffer-overflow considered a "solved problem" ? (at least for future systems) -



Is buffer-overflow considered a "solved problem" ? (at least for future systems) -

i looking @ various buffer/heap/stack protection technologies such pax, dep, nx, canaries, etc

and new 1 smep - http://vulnfactory.org/blog/2011/06/05/smep-what-is-it-and-how-to-beat-it-on-linux/

assuming using latest kernel on latest mainstream processor assuming recompile apps various compiler protections assuming run dep, aslr nx bit whatever protection

is reasonable buffer-overflow attack fail? , has been solved future systems?

as corollary, true implemented, current win7 systems hopelessly vulnerable rot , other techniques particularly on 32bit apps ?

p.s. purposely not going "managed code safe" argument here

[disclaimer] not advocating sloppy coding. realize there many other attacks. know existing systems far outnumber "idealized" security configuration

no, buffer-overflow not solved problem, @ to the lowest degree in unmanaged code.

the basic problem technologies listed (dep/nx, aslr, canaries, smep) happen after fact: cannot solve buffer overflow problem, because not prevent root cause - buffer overflow , memory corruption has already happened.

all of schemes 'good' unreliable heuristic ways effort either observe fault after corruption happens before becomes working exploit, or create hard engineer reliable working exploit.

e.g. dep, aslr, , canaries on windows vista , 7 can circumvented rot plus other techniques, , hence raise difficulty bar of creating working exploit. but, difficulty increment quite significant. point of techniques.

if interested in solving problem @ root preventing original buffer corruption, think productive, bring give-and-take of managed code...

stack-overflow buffer-overflow aslr dep

Comments

Popular posts from this blog

iphone - Dismissing a UIAlertView -

intellij idea - Update external libraries with intelij and java -

javascript - send data from a new window to previous window in php -