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

2 Answers 2


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".


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.

  • 2
    Total time from reading question to doing research to composing answer: 5 minutes.
    – schroeder
    Commented Mar 2, 2015 at 23:37
  • 1
    Note such vulnerabilities are much rarer and harder to find in real life than regular stack buffer overflows.
    – Mints97
    Commented Mar 3, 2015 at 4:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .