"If you want to make sure your computer or server is not tricked into undertaking malicious or undesirable behavior, it's not enough to keep bad code out of the system. Return-oriented programming exploits start out like more familiar attacks on computers. The attacker takes advantage of a programming error in the target system to overwrite the runtime stack and divert program execution away from the path intended by the system's designers. But instead of injecting outside code - the approach used in traditional malicious exploits - return-oriented programming enables attackers to create any kind of nasty computation or program by using just the existing code."
Post a Comment
Member since:
2005-07-07
Member since:
2006-01-10
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.