#1
  1. No Profile Picture
    Junior Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Apr 2002
    Location
    Hyderabad
    Posts
    17
    Rep Power
    0

    Static Variables


    Hi all,

    where static variables will be stored , in data segment or stack segment or in Heap?


    Suri
  2. #2
  3. No Profile Picture
    Contributing User
    Devshed God 1st Plane (5500 - 5999 posts)

    Join Date
    Oct 2000
    Location
    Back in the real world.
    Posts
    5,966
    Rep Power
    190
    i guess it depends on your OS/compiler combo...
    but never in the stack segment!

    since you talk about segments, it is 16bit code, no?

    for 32bit, afaik all data goes on the heap and you could say "data segment == codesegment == heap".

    [disclaimer]
    i am not a compiler pro, so this might be completely wrong...
    [/disclaimer]

    anyway, why do you care?
  4. #3
  5. Banned ;)
    Devshed Supreme Being (6500+ posts)

    Join Date
    Nov 2001
    Location
    Woodland Hills, Los Angeles County, California, USA
    Posts
    9,616
    Rep Power
    4247
    Static variables go to your data segment, along with your global variables. The stack segment is for local non-static variables and arguments passed to functions. The heap is used for carving out dynamically allocated variables (for example, when you use malloc(), calloc(), strdup() etc.)

    As MHirsch pointed out, on a 32 bit compiler, segments don't really exist because of the flat memory model. However, something similar does exists, they are called sections. Most object files have at least 3 sections within them (i.e.)
    data: for initialized global variables
    bss: for uninitialized global variables
    text: for the actual code itself.
    With a 16 bit compiler, each section may occupy its own segment in memory, depending on the compiler settings. BTW the above section info holds true for both gcc and turbo-c. You can see what it puts in each section by generating a map file when you compile a program. In gcc, the option goes something like -Wl,-Map,foo.map and in turbo-c, it is an option in the menu somewhere.

    The linker takes all the obj files and merges the sections individually (i.e. all text sections together, all data sections together etc.) to produce the final executable.

    As an aside, in OpenBSD, they are making an effort in the upcoming versions to mark the data, heap and stack areas of a program in memory as non-executable. This will reduce attacks caused by buffer overflows. Some CPUs (such as Sparc and Alpha) support this natively, but Intels don't and so this has to be handled by the OS.
    Last edited by Scorpions4ever; January 20th, 2003 at 02:12 PM.
  6. #4
  7. No Profile Picture
    Junior Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Apr 2002
    Location
    Hyderabad
    Posts
    17
    Rep Power
    0
    Hi Scorpion4server,

    Thanks for great explanation . Thanks for ur support .

    as per u r reply :

    In OpenBSD, they are making an effort in the upcoming versions to mark the data, heap and stack areas of a program in memory as non-executable. This will reduce attacks caused by buffer overflows.

    Actually i haven't undestood it properly . Can u clarify me in detail .



    Suri
  8. #5
  9. No Profile Picture
    Contributing User
    Devshed God 1st Plane (5500 - 5999 posts)

    Join Date
    Oct 2000
    Location
    Back in the real world.
    Posts
    5,966
    Rep Power
    190
    i wonīt explain the details here, but:

    if you donīt do correct input buffer length checking, one could send a string of 1000 chars into a variable of size 100. once pushed on the stack, it will overwrite the back-jump address of the calling function. if you do this "correctly", it will execute the program code that you put into the string.... HACKED! This is called a "buffer overflow"

    to prevent this, some OSs donīt allow code on the stack to be executed. (for linux there is a patch and a kernel module that can do the same. but i read somewhere that there is programs that rely on code on the stack being executable - bad programming...)
  10. #6
  11. Banned ;)
    Devshed Supreme Being (6500+ posts)

    Join Date
    Nov 2001
    Location
    Woodland Hills, Los Angeles County, California, USA
    Posts
    9,616
    Rep Power
    4247
    Yep, M. Hirsch described the situation pretty accurately there. For a more technical article, check out http://www.insecure.org/stf/smashstack.txt
  12. #7
  13. No Profile Picture
    Contributing User
    Devshed God 1st Plane (5500 - 5999 posts)

    Join Date
    Oct 2000
    Location
    Back in the real world.
    Posts
    5,966
    Rep Power
    190
    i didnīt feel like posting that kind of info here. but now that i think about it...
    I bet there is few script kiddies here and more admins/programmers that will take advantage of this kind of information.

    Iīll start a post in the lounge to see what people think about it...
  14. #8
  15. No Profile Picture
    .
    Devshed Newbie (0 - 499 posts)

    Join Date
    Dec 2002
    Posts
    296
    Rep Power
    12
    > if you donīt do correct input buffer length checking, one could send a string of 1000 chars into a variable of size 100

    i thought that's exactly what causes a segmentation fault error? why doesn't that cause a a segmentation fault?
  16. #9
  17. No Profile Picture
    Contributing User
    Devshed God 1st Plane (5500 - 5999 posts)

    Join Date
    Oct 2000
    Location
    Back in the real world.
    Posts
    5,966
    Rep Power
    190
    segfaults occur if you have an invalid address, but you supply the right "code" and the address is valid since code on the stack or in the data "segment" is allowed. Thatīs the trick. Of course, after the program executed your code, it will probably hang, quit or segfault. But then itīs too late ;)
    Last edited by M.Hirsch; January 24th, 2003 at 12:47 AM.

IMN logo majestic logo threadwatch logo seochat tools logo