Future of Buffer Overrun Attacks to stack execution

[TheCotMan]

Is buffer overflow to stack space, for arbitrary code execution going to be dead in the near future?

From the early attempts to "fix" this with the use of canaries in StackGuard, through to Operating Systems supporting Non-Executable Stack Space, to the more recent addition of support in chips for "NoExecute" on segments (assuming OS support is included) and the newer variations of encrypted return addresses also acting as canaries as well as dynamic relocation of address of programs as they are started (to ruin prepackaged jump addresses for exploits) and the many others, what is the future of buffer overruns as a stack overflow and arbitrary code execution method of entry?

And the next question, if we assume that all of these work-arounds actually prevent execution of arbitrary code on stacks as pushed through buffer overruns, will this encourage MORE bad coding? Will lack of attention to "security issues of buffer overruns" cause businesses to care less about such bugs, and leave more crappy software without fixes?

(I know there are people who are professionals here, but I'm not sure they'll want to talk "work" while on the forums. If this thread goes nowhere, I totally understand.)

[Added:]
x86-64 and page permissions. (From Bascule)
(PDF) On StackGuard and use of canaries and gcc

[dYn4mic]

I think this is quite a vaild question with vast implications....
I'm no "security professional", but here is what I think on the non-technical aspects (because I don't feel knowledgeable enough to make claims about future Buffer overflow tactics.)
From looking at other fields, technical and non... I think that if we stop education and awareness of BAD programming... Security/other problems will continue to plauge us all. Overflows or other new ones....

If we let people say 'i'll leave it to the compiler' or 'this server is just going to be running <insert ken. patch here>, so it'll be ok'....
We'll have more problems because of a lack of security awareness. They will just take the shape of other abuse. (Its also the problem of bloatware.)
More security or bug testing isn't really the solution, nor is a bandage like stackguard or others. (And don't blame it all on C...)
Even by education and advocacy of teachers, security is a mindset, not a checklist.
Maybe software must also go through a long security test phase?
People could be held accountable for bad software?

But its a never ending problem, as im sure many of us know. It only takes one domino to knock them all down, but if we arrange them right.... it does nothing.
(Until someone thinks of something we (or a team even) havn't... which is always a possibilty) Like just blowing the dominos down with a leaf blower :-P. Or blowing up the rackspace with a tru.ckb_om_b.

[TheCotMan]

I think that if we stop education and awareness of BAD programming... Security/other problems will continue to plauge us all. Overflows or other new ones....

Yep. I am worried that if there is a 100% solution to protecting a system from running arbitrary code [over the short term] through buffer overrun and execution of stack code, we'll see what happened when "firewalls" were added to businesses-- employees just used simple password and claimed, "I don't have to use strong password, because we have a firewall."

Security in software seems to be an issue mostly because of media spotlight tarnishing name recognition, and/or as a result of ethical sales/R&D/customer-satisfaction/coding.

If a business does not see an advantage to paying attention to checking buffers/tainted data, will emphasis to avoid these problems decrease? (Sure, stability issues may eventually be resolved, but they seem to get resolved later than security fixes.)

...They will just take the shape of other abuse.

Good point. Look at the increase in attacks based on invalid trust models (not bugs in syntax) in comparison to buffer overrun attacks in how e-mail worms have been spreading. Even a combination of malware code and social attacks in the form of early e-mai worms, that ask the user to examine the attachment don't need buffer overruns to be successful..

Its also the problem of bloatware.

I have a good idea for a thread topic on this, so I'll have to save that for later. :-)

Maybe software must also go through a long security test phase?

Good idea for stability and security, but bad for "being first to a ground of contention," and for market share is a big deal. (The Art of War)

People could be held accountable for bad software?

This has been proposed, but some businesses might just pass the buck. Maybe they would hire coders as "independent contractors" and if legal accountability was theirs, the company would just end the contract and get another contractor. Maybe they would just add it to the shrinkwrap EULA for customers to waive that right. Also, there have been good discussions on how this would impact OpenSource.

[genjix]

I think it is *alot* better to redirect security from into the hands of incompetent coders (we are human after all) into compilers and the operating system.

On another note I have noticed that in the newer versions of SUSE (not running SELinux), that buffer overflows using strcpy didn't work. :)

[bascule]

Hmm, deja vu... (Ed: bleh, beaten to it! Guess all those conversations were with CotMan anyway)

[TheCotMan]

Hmm, deja vu... (Ed: bleh, beaten to it! Guess all those conversations were with CotMan anyway)

Yep. I tried to offer references to the discussions we had (and this is why I cited your thread in the original), but wanted to take the discussion in a different direction... If we assume a solution is found that is 100% (even for a limited time) will that lead to even worse coding practices and even worse support for applications in the market with slower releases on bug fixes.

I really liked the discussion we had on this last year, but did not want to bring back the 1.5 year old thread or the 1 year old thread only to move with the similar topic (buffer overrun elimination) but in a different direction; this discussion does not need to be technical-- only opinion and future prediction.

[Heh. I notice many of the technical discussions on compiler, OS, and system tend to not be as popular as the social ones.]

[d.fi]

Yes, overflows will be replaced by application-level attacks

Spoonm (of Metasploit fame) and I were just having this conversation a few weeks ago, and we both think that there will be pretty wide-spread use of technologies to defeat buffer overflows over the next few years. The will be replaced by application-level attacks, which we are already seeing with SQL injection etc. That is at least the opinion of this "security professional" and Spoonm (a hardcore shellcoder).