stack vs. heap

[n4nature]

If there is no memory available, memory allocation in heap returns a NULL ptr, and we can detect it by checking for NULL. How can I detect memory unavailablity on stack?

[writetonsharma]

i think you cant detect, a stack overflow will occur.
every process has one stack, with each function call the functions, variables etc etc are stored on the stack(stack winding) and as the function returns the stack is unwinded..

stack overflow bugs can corrupt the data and crashes.

in assembly i think you can control the stack.

[n4nature]

THanks. So we cannot do anything about it? That's really nasty :)

[writetonsharma]

i think so.. let some other replies come.. :)

[jsmith]

There's nothing you can do that isn't a total hack.

[writetonsharma]

jsmith:

what was that..!!! :o

[Gumbercules]

I think he just meant, "there's nothing one can to do (to check if memory is available for stack) that isn't a total hack"

[writetonsharma]

hehehehe... hmmm..

[writetonsharma]

point of interest:

a buffer overflow can cause the stack to corrupt and even can cause the return address to change to some other address.. now when the stack unwind it start to execute the wrong code as the return address is changed which was set by buffer overflow.. the attacker can gain access to the whole system also.

any comments???

[kaidranzer]

well the code that is executed when the stack unwinds depends on where the esp(stack pointer) points and eip (instructor pointer) points to the place where the program is being executed so if an attacker wants to make the system to execute the wrong code then he has to basically make the eip point to that piece of code. To achieve that he has to first find the address that contains jump_eip once he finds it he can make eip point to anywhere he wants.
This also makes use of overwriting the return address of the function that is being executed to gain contrl of the esp so that the wrong code can be placed there.........

[jsmith]

Sorry, I just realized my post was an unintentional double entendre. Of course I meant as Gumbercules said.

[n4nature]

1) I found online that for Windows stack memory is 32MB, for Linux it is 8MB. These are awefully low numbers considering the size of the programs run these days. I'd think those programs could easily reach these limits.

2) Is it then a good idea to always allocate and deallocate via "new/delete", to avoid the stack overflow problem? Specially for the large programs, who knows how much stack memory is being used by future programmers. I don't think anybody keeps track of how much stack memory is being used.

[writetonsharma]

1. if this is true then 8MB is not a low memory.. A program cant reach to that limit..
8 mb means 8388608 bytes.. and you mostly declare variable which are 4 bytes or 8 bytes or structures/classes which may be lets say 100 bytes in size.. these are approximate sizes.. and if we assume that our average variable size is 100 bytes.. which generally is very less than that..

to overflow the stack you need atleast 8000 variables.. i dont think a stack can be loaded with 8000 variables at one time.. and being human no one can handle 8000 variables.. so making a stack overflow is quite difficult..

and secondly we all here must be working on some software which has millions of lines of code.. i dont think anyone here has seen the stack overflowing..

2. doing new/delete for each variable is not a good idea.. this will lead to low performance of the program as memory is allocated and freed very often and chances of memory leaks.

[kaidranzer]

well i have seen the stack overflowing. If you want to just download a freeware warftp , attach a windows debugger to it , enter a long long user name (say a series of As) and you can see the program crashes. The developer has actually forgotten to do bound checking for the username array. Observe that windows debugger shows esp pointing to 41414141 that is corresponding to AAAA

[writetonsharma]

hmmmm... yes your are right.. ok i change my statement.. but in normal circumstances its not possible.. correct??
otherwise one can do anything.. crashing stack, exhausting system memory and all kind of hacks..

[jsmith]

kaidranzer: that's just a programming bug that resulted in a buffer overflow, which is different than a stack overflow. Chances are that app was using only a few bytes of stack, but that's what happens when you try to read user input into a fixed length array on the stack.

Stacks are typically big. The general rule of programming I go by is to make local variables when the variable is only needed in that scope and use new/delete when the lifetime of the variable must exceed that of the block in which it is declared. However, I might be coerced into using new/delete if a local variable is huge, but in most cases it isn't. Consider vector, for example. If you allocate an STL vector on the stack, no matter how many elements of whatever size you put into the vector, it still only uses about 12 bytes of stack space because the object internally allocates the elements on the heap.

[Deimos]

Well, well, someone's been reading Jon Erickson's Hacking: The Art of Exploitation. ehehehehe xD
Great book, in my opinion :)
Abou the stack thing, I never had problems overflowing it in my programming life, so I guess it's big enough! :D
Taking in consideration the level of abstraction towards the machine we currently have, I'd say that many precautions must have been made by people (like our idol Bjarne Stroustrup [:)]), in order to avoid low-level crashes like stack overflows.
By the way, if this is a total nonsense please do correct me. :)

Best Regards
~Deimos

[kaidranzer]

nah i havent been reading any book i just attended an ieee lecture on stack overflows few days ago so its still fresh :)

[writetonsharma]

thats why i was wondering how can someone give such a accurate description of buffer overflow attacks as if he's writing one..
hehehe... :D

check out this for details:

http://insecure.org/stf/smashstack.html

[kaidranzer]

great thats looks fun