-3

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?

radscheit
  • 99
  • 6
  • How much space do you have in the heap? the stack? –  Feb 09 '16 at 21:01
  • Aren't they sharing the same physical memory? – radscheit Feb 09 '16 at 21:03
  • 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 09 '16 at 21:03
  • Did I get you right, you refer to the fact that stack is organized in LIFO and heap is randomly? – radscheit Feb 09 '16 at 21:05
  • From a Java world, not necessarily. `-Xmx:` and `-Xss:` though note that that stack size is on a *per thread* basis. –  Feb 09 '16 at 21:06
  • Oh I understand, sorry I shoukd have written that I have generally x86 in mind. I will add this information to the question. – radscheit Feb 09 '16 at 21:07
  • 1
    @radscheit in a related question, I would suggest reading [this answer](http://programmers.stackexchange.com/a/197824/40980) 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. –  Feb 09 '16 at 21:12
  • @MichaelT Thanks, that makes sense to me, but my question is more conceptual in fact that I don't plan to try an overflow on any certain system. I heard the statement in the question in a keynote and now I#m thinking about it. There was no certain system addresed in this statement. – radscheit Feb 09 '16 at 21:17
  • 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 09 '16 at 21:38
  • @Jonah Thanks for asking. It was a course at my university called Internet Security, which I plan to visit in the next semesters. Some buzzwords were: stack canary, exploitation, controlled and uncontrolled buffer overflow. – radscheit Feb 09 '16 at 21:41
  • 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 09 '16 at 22:08

1 Answers1

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

Erik Eidt
  • 33,282
  • 5
  • 57
  • 91