Bugtraq mailing list archives
Re: More ELF buggery...
From: Julien Vanegue <vanegu_j () epita fr>
Date: 31 May 2002 16:02:46 -0000
In-Reply-To: <3CF1148A.7060301 () gmx net> Hi, This technique was known years ago by random people, note that gdb use it to resolve internal library symbols and put breakpoints on it (since shared libraries are ET_DYN objects, their absolute virtual address is not known at the process launching, thats why we need the linkmap) The link_map can also be really useful in infoleak bugs, possibly for bypassing full random address space protection as implemented by PaX 2.0 + et_dyn.zip and the advised relinking (ET_EXEC to ET_DYN using -shared and creating a valid entry point) . The linkmap can also possibly be used to hijack function calls using hash table poisoning, so that the dynamic linker would fill the .got with your own value at the first function call . You can do with it actually . I wont post the text called 'ELF dynamic linking on x86 LINUX' written by myself where you can find 3 Dynamic linker implementation . (...) B) The link_map structure explained . (...) However this has been distributed in the past to a few person including yourself, but I know for sure that you knew about it before :) Why did you release that ? --------- mayhem
A process image is a collection of one or more objects mapped into a common address space. The dynamic linker co-ordinates symbol resolution, and effectively communication, between these objects. The linker uses a link_map structure to keep track of each object's location and symbol resolution data. The link_map structure is pointed to by a reserved entry in the GOT of each object and retrieved by the dynamic linker when required. The link_map structures are also linked together in a doubly linked list.
This list is traversed by the
dynamic linker when it attempts to resolve a symbol.
Current thread:
- More ELF buggery... the grugq (May 27)
- <Possible follow-ups>
- Re: More ELF buggery... Julien Vanegue (May 31)