Your post is indeed very useful, but for the sake of completeness I'll add some remarks to it.
The technique you call Return Oriented Programming is not as new as you seem to beleive. It evolved from ideas and techniques that have been arround since late 90s, mainly what is called "return to lib". Surely it was not as popular and hyped as it is today, but then again neither was a non-executable stack popular back then.
Also an effective implementation of Address Space Layout Randomization serves as a mitigation to ROP shellcode. I'm no expert on exploit writing but I beleive that modern ASLR on 64 bits system will be very difficult to bypass except for the most skilled exploit writers out there, and they would most surely need to pinpoint exact versions of your OS, libraries and layout of your binary.
I don't know any specifics about your work, but though "You can't. Don't make any buffer overruns" is a very good advice, its rather simple-minded... I firmly believe any bug can be leveraged into code execution until someone shows the contrary for said bug, but that doesn't mean that a single technique is the silver bullet of exploit writing. To be able to code in a security-minded way, as one learns about were each protection might fail, one must also learn about how each exploit writing technique might fail.
A good introduction to ROP in the form of a somewhat self oriented self contained blogpost can be found here:http://eticanicomana.blogspot.com/2010/06/so-called-return-o... by a guy from Immunity Inc. I'm mentioning his post because I think one of the automated gadget finding tools you may be talking about is their Immunity Debugger/DEPLib.
I agree with you, and I didn't mean to imply that ROP is all that new. It's been on my personal radar since 2008, which is when it became really popular. I think this was also when the automated tools for exploits started to appear. Of course, the basic techniques go back before then. This happens with computer science - we had to give up writing a certain patent [not security-connected] because we found the basic idea in a paper from 1956.
We discussed address space randomization, which of course we use, and our conclusion was that for us, this doesn't provide enough protection. Not every location can be randomized with equal effectiveness, and sometimes just having an offset is enough, and we're a high-value target. Thus, the advice to "not make buffer overruns." I am also not an exploit writer, or even specifically a security guy (although I need to be aware of it). Obviously, return-oriented programming is not a "we're all going to die!!!" thing. But it's an extremely dangerous technique, which really illustrates the danger of writing user-facing code in a language with no memory safety.
The technique you call Return Oriented Programming is not as new as you seem to beleive. It evolved from ideas and techniques that have been arround since late 90s, mainly what is called "return to lib". Surely it was not as popular and hyped as it is today, but then again neither was a non-executable stack popular back then.
Also an effective implementation of Address Space Layout Randomization serves as a mitigation to ROP shellcode. I'm no expert on exploit writing but I beleive that modern ASLR on 64 bits system will be very difficult to bypass except for the most skilled exploit writers out there, and they would most surely need to pinpoint exact versions of your OS, libraries and layout of your binary.
I don't know any specifics about your work, but though "You can't. Don't make any buffer overruns" is a very good advice, its rather simple-minded... I firmly believe any bug can be leveraged into code execution until someone shows the contrary for said bug, but that doesn't mean that a single technique is the silver bullet of exploit writing. To be able to code in a security-minded way, as one learns about were each protection might fail, one must also learn about how each exploit writing technique might fail.
A good introduction to ROP in the form of a somewhat self oriented self contained blogpost can be found here:http://eticanicomana.blogspot.com/2010/06/so-called-return-o... by a guy from Immunity Inc. I'm mentioning his post because I think one of the automated gadget finding tools you may be talking about is their Immunity Debugger/DEPLib.