Return to Answer

With a stack overflow - if you just keep overflowing - you overflow first locals vars, then saved registers, then return address, then function arguments, then stuff further down the stack, maybe exception handlers, etc. Usually as an attacker you indeed use the overwritten return address to jump somewhere interesting.

With a heap overflow you overflow ... whatever lies beyond your piece of memory. In old or bad heap implementations that might be heap metadata that can give you e.g. the power to write stuff into targeted memory locations (which you could use to overwrite a function pointer). In other heap implementations you will have to engineer a pattern of allocations and deallocations to get the heap into a state where there is an interesting allocated piece to the right side of your piece of memory. Maybe a vtable or some other function pointers.

Heap overflows are highly specific to heap implementation and application. On linux there are the „house of ...“ techniques because glibc malloc is a joke (sorry!), on windows 7 the heap got very well secured and well randomized and you have to hope for applications to bring their own insecure heap implementations to get 1% more performance. They often do.

With a stack overflow - if you just keep overflowing - you overflow first locals vars, then saved registers, then the return address, then function arguments, then stuff further down the stack, maybe exception handlers, etc. Usually as an attacker you indeed use the overwritten return address to jump somewhere interesting.

With a heap overflow you overflow ... whatever lies beyond your piece of memory. In old or bad heap implementations that might be heap metadata that can give you e.g. the power to write stuff into targeted memory locations (which you could use to overwrite a function pointer). In other heap implementations you will have to engineer a pattern of allocations and deallocations to get the heap into a state where there is an interesting allocated piece to the right side of your piece of memory. Maybe a vtable or some other function pointers.

Heap overflows are highly specific to heap implementation and application. On linux there are the „house of ...“ techniques because glibc malloc is a joke (sorry!), on windows 7 the heap got very well secured and well randomized and you have to hope for applications to bring their own insecure heap implementations to get 1% more performance. They often do.

With a stack overflow - if you just keep overflowing - you overflow first locals vars, then saved registers, then return address, then function arguments, then stuff further down the stack, maybe exception handlers, etc. Usually as an attacker you indeed use the overwritten return address to jump somewhere interesting.

With a heap overflow you overflow ... whatever lies beyond your piece of memory. In old or bad heap implementations that might be heap metadata that can give you e.g. the power to write stuff into targeted memory locations (which you could use to overwrite a function pointer). In other heap implementations you will have to engineer a pattern of allocations and deallocations to get the heap into a state where there is an interesting allocated piece to the right side of your piece of memory. Maybe a vtable or some other function pointers.

Heap overflows are highly specific to heap implementation and application. On linux there are the „house of ...“ techniques because glibc malloc is a joke (sorry!), on windows the heap got very well secured and well randomized and you have to hope for applications to bring their own insecure heap implementations to get 1% more performance. They often do.

With a stack overflow - if you just keep overflowing - you overflow first locals vars, then saved registers, then return address, then function arguments, then stuff further down the stack, maybe exception handlers, etc. Usually as an attacker you indeed use the overwritten return address to jump somewhere interesting.

With a heap overflow you overflow ... whatever lies beyond your piece of memory. In old or bad heap implementations that might be heap metadata that can give you e.g. the power to write stuff into targeted memory locations (which you could use to overwrite a function pointer). In other heap implementations you will have to engineer a pattern of allocations and deallocations to get the heap into a state where there is an interesting allocated piece to the right side of your piece of memory. Maybe a vtable or some other function pointers.

Heap overflows are highly specific to heap implementation and application. On linux there are the „house of ...“ techniques because glibc malloc is a joke (sorry!), on windows 7 the heap got very well secured and well randomized and you have to hope for applications to bring their own insecure heap implementations to get 1% more performance. They often do.

With a stack overflow - if you just keep overflowing - you overflow first locals vars, then saved registers, then return address, then function arguments, then stuff further down the stack, maybe exception handlers, etc. Usually as an attacker you indeed use the overwritten return address to jump somewhere interesting.

With a heap overflow you overflow ... whatever lies beyond your piece of memory. In old or bad heap implementations that might be heap metadata that can give you e.g. the power to write stuff into memory (which you could use to overwrite a function pointer). In other heap implementations you will have to engineer a pattern of allocations and deallocations to get the heap into a state where there is an interesting allocated piece to the right side of your piece of memory. Maybe a vtable or some other function pointers.

Heap overflows are highly specific to heap implementation and application. On linux there are the „house of ...“ techniques because glibc malloc is a joke (sorry!), on windows the heap got very well secured and well randomized and you have to hope for applications to bring their own insecure heap implementations to get 1% more performance. They often do.

With a stack overflow - if you just keep overflowing - you overflow first locals vars, then saved registers, then return address, then function arguments, then stuff further down the stack, maybe exception handlers, etc. Usually as an attacker you indeed use the overwritten return address to jump somewhere interesting.

With a heap overflow you overflow ... whatever lies beyond your piece of memory. In old or bad heap implementations that might be heap metadata that can give you e.g. the power to write stuff into targeted memory locations (which you could use to overwrite a function pointer). In other heap implementations you will have to engineer a pattern of allocations and deallocations to get the heap into a state where there is an interesting allocated piece to the right side of your piece of memory. Maybe a vtable or some other function pointers.

Heap overflows are highly specific to heap implementation and application. On linux there are the „house of ...“ techniques because glibc malloc is a joke (sorry!), on windows the heap got very well secured and well randomized and you have to hope for applications to bring their own insecure heap implementations to get 1% more performance. They often do.