-2

Why is it more difficult to perform a heap based buffer overflow than a stack based? (regarding x86 architecture)

I thought it could be the fact that heaps are allocating memory dynamically. But is there more than this?

closed as unclear what you're asking by user40980, Ixrec, user22815, GlenH7, MetaFight Feb 14 '16 at 19:41

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • How much space do you have in the heap? the stack? – user40980 Feb 9 '16 at 21:01
  • 2
    I would assume it's because in a heap based overflow, it's very hard to predict what memory you'll clobber with your overflow, assuming you don't immediately seg fault, whereas a stack based overflow is almost certainly going to hit parts of your stack frames in a somewhat predictable (albeit machine-dependent) order. But I may be making some invalid assumptions about how heap memory is allocated and segmentation faults are detected. – Ixrec Feb 9 '16 at 21:03
  • 1
    @radscheit in a related question, I would suggest reading this answer which notes: "The answer is clearly platform dependent, compiler dependent and even library dependent." even with x86, the ability to tickle a stack overflow or a heap overflow and the severity of each is something that depends on the compiler and libraries in use also. – user40980 Feb 9 '16 at 21:12
  • 1
    @radscheit if you can cite this source it might provide some useful context. Do you know if this was specifically about the difficulty of triggering an overflow? Could it have referred to the complexity of exploiting an overflow? – Jonah Feb 9 '16 at 21:38
  • 1
    Terminology: this is why "overflow" is not a technically unambiguous word. Instead, please clarify whether it is "overrun" - overwriting of memory space located outside (at some higher address) of an object, or "exhaustion" - merely a failure to request allocation of more memory. Exhaustion typically leads to orderly or abruptly shutdown; "overrun" in unmanaged environments (such as C, C++) leads to undefined behavior, with the possibility of data corruption, altered program behavior (not statically analyzable) or arbitrary code execution. – rwong Feb 9 '16 at 22:08
5

They do share the same physical memory, however, the stack frame contains return addresses.

Return addresses store the address of the code in the calling function/procedure/method, so that the called function/procedure/method knows where to go back to when it is done. Mechanically, the "return" statement issues instructions to the processor to load the return address from the stack frame, then unload the stack frame and jump to that loaded return address. (The call operation effectively does the reverse: capture current address as return address and push that onto the stack along with a new frame.)

One problematic security issue is hijacking the processor program counter, which tells it what instructions it is going to execute next!

If you overwrite the return address in the stack frame, you can make the "return" code branch to a location of your choosing instead of where it should go (back to the caller).

  • Thanks, actuallly I'm not allowed to upvote yet because of my low reputation, but I would if I could! – radscheit Feb 10 '16 at 6:48

Not the answer you're looking for? Browse other questions tagged or ask your own question.