http://www.osnews.com/story/20511/Good_Code_Bad_Computations_a_Computer_Security_Gray_Area Exploring the Future of Computing en-us Copyright 2001-2009, David Adams adam+nospam@osnews.com Tue, 10 Nov 2009 01:53:59 GMT http://www.osnews.com/images/osnews.gif http://www.osnews.com http://osnews.com/thread?336823 http://osnews.com/thread?336823 I guess that this proves that ASLR and SSP is necessary. Some have argued that it is just a bandaid to badly coded software. Now it seems that even well coded software can benefit from having these protections in place as well. Mon, 10 Nov 2008 15:30:00 GMT donotreply@osnews.com (abraxas) Comments http://osnews.com/thread?336874 http://osnews.com/thread?336874 You know, normally in an article we get links for every pointless keyword Here is a great article and apart from the term 'return-oriented exploits', I have no idea what this all means.

This seems like a good link:
http://www-cse.ucsd.edu/~savage/papers/CCS08GoodInstructions.pdf

Basically it is your standard stack however. However, instead of jumping to malicious code provided by the evil person, it jumps to good code that does bad things.

For example a a malicious code exploit would do the following:
1. Load some bad code into memory
2. trick the stack into executing this bad code (buffer overflow...)

This kind of attack is stopped by making sure the 'bad code' is unable to execute. For example by memory as not executable.

The return-oriented exploit does not need to load bad code into memory so it can bypass the non-executable safety net. What it does do however is trick the stack into jumping to currently running good code. For example jumping to a standard libc call. However, by executing the libc calls in a particular order and what not, it can be made to do bad things. The link above explains it best. Mon, 10 Nov 2008 20:22:00 GMT donotreply@osnews.com (Yamin) Comments