Does preventing buffer overflow attacks prevent ROP attacks?

Question

Would preventing buffer overflow attacks prevent Return Oriented Programming (ROP) attacks?

Answer 1

ROP is about leveraging an initial execution thread hijack into arbitrary code execution even in situations where the OS tries to prevent just that (with DEP and ASLR).

By "execution thread hijack" I mean that the attacker succeeds in making execution jump to an unforeseen place, normally by overwriting a memory slot that the application code will later on interpret as a pointer to code. Traditionally, that slot is the return address of the current function (on the stack, used upon function exit) or a function pointer (typically from a vtable in C++ code), and the overwrite is enacted through a buffer overflow. However, any other kind of overwrite may conceptually be used; for instance, a use-after-free can sometimes be turned into an arbitrary jump.

In any case, ROP is not about how you get the target system to derail, but what you do from that point onwards. In that sense, there is no such thing as a "ROP attack".

Answer 2

A quick Google search says "no". The original paper from the original presentation (Section 4.2) says that although Buffer Overflow is easiest, it is not necessary.

However, a stack overflow isn’t necessary. The payload containing the return-oriented program could be on the heap, and the attacker could trigger its execution by overwriting a function pointer with the address of a code snippet that sets %esp to the address of the first gadget and executes a return.