Sorry, I think I have forgotten some of the details discussed before :-). On Mon, Mar 24, 2008 at 11:44 PM, Peter Teoh <htmldeveloper@xxxxxxxxx> wrote: > I don't think there is any end_stack, as it depends on how much of > heap memory u are using. Heap memory grows towards small-->big, and > stack is reverse (for x86), therefore, whoever use more memory, the > other will have less. That at least is for traditional OS. > This is generally true for general OS - Linux in the past (pre-vDSO) and Windows, exception are like IBM390, where the stack pointer grow downwards instead of upward. > But in Linux, check /proc/pid/maps, there is a vdso memory region, > just above the stack region. This therefore limits the size of the > stack to a fixed value. (purpose of vdso is related to buffer > overflow protection - when u use gdb to attach to any existing > process, and attempt to read that memory, it is not > readable/accessible, overflowing the stack into this region will Sorry, I was wrong, it is both readable, and overwritable: (gdb) x/100x 0xb7fe6ff0 (gdb) set *0xb7fe6ff0=0x99 Both the above are possible after attaching to the process, and verifying it against /proc/pid/maps. b7fd1000-b7fd3000 rw-p b7fd1000 00:00 0 b7fe6000-b7fe7000 r-xp b7fe6000 00:00 0 [vdso] bffd2000-bffe7000 rw-p bffeb000 00:00 0 [stack] > therefore segfault). and immediately following this vdso is the heap Sorry, my mistake again. What I mean was immediately BEFORE the vdso is the heap (shown as unlabelled above). > - I think so, as maps did not label it currently. > So, based on the traditional heap grow downwards, and stack upwards, they will still meet at vdso, overwriting its content in the scenario of buffer overflow. START of vdso is randomized, as indicated here (for buffer overflow protection): http://lwn.net/Articles/190139/ http://en.wikipedia.org/wiki/Address_space_layout_randomization And here ===> stack starting address is randomized. http://lwn.net/Articles/121845/ http://searchenterpriselinux.techtarget.com/tip/0,289483,sid39_gci1144658,00.html To quote from 121845: Arjan responds that the amount of randomization is not the issue at the moment. He is trying to get the infrastructure into the kernel and tested in a minimally disruptive way; the degree of randomization can be tweaked upward later on. That amount may never get as high as some people would like, at least on 32-bit systems, because it cuts back on the available virtual address space. But it is likely to go up once the developers are convinced that things are working. In any case, a larger randomness makes the problem harder, but does not change its fundamental nature. With the ability to keep trying, an attacker will eventually get around any degree of randomization possible on 32-bit systems (64-bit systems are a different story). Thus, says Ingo Molnar: conclusion: stack randomisation (and other VM randomisations) are not a tool against local attacks (which are much easier and faster to brute-force) or against targeted remote attacks, but mainly a tool to degrade the economy of automated remote attacks. Randomization is not a magic bullet which solves a wide range of security problems. It does make an attack harder, however, and that can only be a good thing. Thanks :-). -- Regards, Peter Teoh -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
