Re: More ELF buggery...

[Julien Vanegue <vanegu_j () epita fr>]

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.