Hi.
On Thu, May 02, 2002 at 10:14:44PM +0200, SpaceWalker wrote:
> Speeking of linux. It may be possible that on some arch, linked with some
> exotic compiler, the .dtors section is after the bss. That's theoricaly
> not impossible, and I don't see why some linker wouldn't do that, except
> the risk of exploiting a such vulnerability.
It is not possible, at least if the file follows the ELF specs. The .bss
section is always put at the end of the data segment (the 2nd PT_LOAD
segment usually, but could be anywhere). This is to avoid eating up space in
the file. The .bss is sloppily translated as "better save space", and thats
only possible when its put at the end of an in-runtime extended segment (or
with just runtime-space-only sections following in that segment).
This has to be the case, since .dtors is always initialized. Initialized
data cannot be put after the end of p_filesz within that segment.
Mhh... if one is very odd he can construct a valid ELF file with three
segments that has the .dtors section after the .bss section in memory, but
no linker will do that on its own ;)
> imagine
> #include <blah.h>
> char buffer[128]; /* I don't remember if the bss grows down or up. */
The .bss never grows. Its fixed at compile time ;)
> int *ptr1;
> int random;
> int main(int argc,char **argv){
> int something=1;
> ptr=&something;
> random=31337;
> strcpy(buffer,argv[1]);
> *ptr=random;
> return 0;
> }
> of course, it's only an example, but it's exploitable and does not contain
> any malloc.
Indeed its exploitable, this uses the same techniques as shown by Lam3rZ in
Phrack and Shok in his heap overflow paper (before the malloc-age ;).
> SpaceWalker
ciao,
scut :)
--
-. scutat_private-berlin.de -. + http://segfault.net/~scut/ `--------------------.
-' segfault.net/~scut/pgp `' 5453 AC95 1E02 FDA7 50D2 A42D 427E 6DEF 745A 8E07
`- complete HTCIA database obtained, exchange as usual. hi echelon ----------'
This archive was generated by hypermail 2b30 : Fri May 03 2002 - 11:20:23 PDT