Hi Sin, >I'm working on Gera's insecure programing stuff, currently on abo7; as i >understand it, this is unexploitable on most (all?) current platforms >because of the order the sections are linked in? I haven't looked at Gera's examples so my answers are based entirely on the issues you mentioned. >1) what exactly is .dynamic used for? The dynamic section corresponds exactly to the dynamic segment, it exists to provide important information to the dynamic linker at run time. It's quite well covered in the ELF specification, which can be found translated into plain text at: http://www.muppetlabs.com/~breadbox/software/ELF.txt >I mean obviously its something to do >with dynamic data of some sort, I assume libc symbol stuff? What I am more >asking is, where can I find more information on it; what exactly belongs >where in .dynamic? The following is a typical dynamic segment: bash-2.05b$ readelf -d /bin/ls Dynamic segment at offset 0xf4b0 contains 21 entries: Tag Type Name/Value 0x00000001 (NEEDED) Shared library: [librt.so.1] 0x00000001 (NEEDED) Shared library: [libc.so.6] - These are the shared libraries needed by the program, expressed as offsets into the dynamic string section 0x0000000c (INIT) 0x80490d4 0x0000000d (FINI) 0x80538bc - These are pointers to the initialization and termination functions, optional 0x00000004 (HASH) 0x8048148 0x00000005 (STRTAB) 0x804893c 0x00000006 (SYMTAB) 0x80483bc 0x0000000a (STRSZ) 943 (bytes) 0x0000000b (SYMENT) 16 (bytes) - These point to the symbol tables and hash tables used to resolve external symbols needed by the program, e.g printf 0x00000015 (DEBUG) 0x0 - This is a pointer to dynamic linking debug information, filled in at run time 0x00000003 (PLTGOT) 0x8058594 0x00000002 (PLTRELSZ) 640 (bytes) 0x00000014 (PLTREL) REL 0x00000017 (JMPREL) 0x8048e54 0x00000011 (REL) 0x8048e2c 0x00000012 (RELSZ) 40 (bytes) 0x00000013 (RELENT) 8 (bytes) - These point to various relocation information indicating how the executable image should be modified in order to be able to reference and call external symbols 0x6ffffffe (VERNEED) 0x8048d9c 0x6fffffff (VERNEEDNUM) 2 0x6ffffff0 (VERSYM) 0x8048cec - These point to versioning information which allows the executable to require particular versions of libraries/functions 0x00000000 (NULL) 0x0 - The dynamic segment always ends with a NULL entry >(this question applies to really all sections; where >can i find specific information pertaining to like the plt, rplt, etc; ive >read some about them, and i have a working idea of what they do, just >looking for more details) In the ELF specification >2) there is no way i can just overwrite .dynamic and change the 0's to say >01's is there? Hmmm... this could possibly work, the dynamic linker reads most of the information it needs before it begins process execution, from then on it only needs the dynamic section when it is called to resolve external symbols. Perhaps if you used the LD_BIND_NOW environment variable to resolve all symbols immediately at startup the section could be safely overwritten. Not sure. >3) how far back into gcc history do i need to dig to get a version that >assembles the sections in a different order. (is this a gcc thing? an as >thing? or a glibc thing? [i realize this isnt gnu specific]) This isn't a gcc thing, it's a GNU ld (linker) thing. But I wouldn't get my hopes up about finding one that does things much differently. Cheers, Shaun
This archive was generated by hypermail 2b30 : Tue Jun 03 2003 - 11:52:24 PDT