Mayhem writes.. > > > 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) Yah.. It's pretty cool. I think GNU is a little crazy with the DT_DEBUG tag they use.. useful though since if you don't use lazy binding, then the rtld wont fill in the "necessary" information into the got, so you can grab the link map list. Hmm.. If I think about this a little more, it might even stop other attacks using the runtime linker that use GOT[1/2] ;-) if (l->l_info[DT_JMPREL] && lazy) { ... got[1] = (Elf32_Addr) l; /* Identify this shared object. */ ... got[2] = (Elf32_Addr) &_dl_runtime_profile; I guess not using lazy binding is an undocumented feature or something. Thankfully however, the nice architecture specific standardization for linking DT_DEBUG tag is neatly filled in with the r_debug structure, which has a nice member to give us the link map list when we really want it. Also, consdering that its a requirement of the ELF specs to include the PLTRELSZ tag when your using runtime linking (by having a PT_INTERP phdr present), maybe some sanity checking etc wouldn't go astray of relocation offsets etc.. some nice extra asserts I love this one already present --> /* Sanity check that we're really looking at a PLT relocation. */ assert (ELFW(R_TYPE)(reloc->r_info) == ELF_MACHINE_JMP_SLOT); how about another to say the relocation offset is reasonably sane? i'm thinking something like this to help out.. (you guyz will have to shuffle a couple lines of initialization code etc out into the main body of code, but thats np). assert(reloc_offset < l->l_info[DT_PLTRELSZ].d_val) not a rather complete solution, but seems moderately useful. i mean, everyone has access to the link maps anyway at this point, so sanity checking a modified link map doesnt provide much *shrug* > 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) . This shouldn't be confused with nergals article with pax on a partial randomization of the address space which he desribes in his paper. Perhaps he missed this part of the Pax documentation which describes how to randomize the start address etc of other things like plt/got of the binary being executed etc (I cant remember seeing this in nergals paper, so I might be confused here)? I can't imagine that the Pax team forgot to say this in any email(s) (??) that talked about this with nergal? I'm sure there is a bugtraq thread which discusses this or something similar though (probably from a couple years ago in discussing exploits against non executable things) I might be going a little forgetful though.. Its an excellent paper though I must say (of nergals), but just a little strange that Pax documentation wasn't there when necessary?? > 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 . This sounds pretty cool actually :) > I wont post the text called 'ELF dynamic linking > > on x86 LINUX' written by myself where you can find > man.. u r 0bvi0zly a f4me/m3d1a wh0re wh0r3. yo. ch3ck 0ut 7h1z c0d3 1 f0und 1n Gl1bc. /* We assume that the string table follows the symbol table, because there is no way in ELF to know the size of the dynamic symbol table without looking at the section headers. */ while ((void *) symtab < (void *) strtab) i guezz i'm silly though and misread the following parts of the ELF specs --> " + Figure 2-14: Symbol Hash Table nbucket nchain bucket[0] ... bucket[nbucket - 1] chain[0] ... chain[nchain - 1] " "The number of symbol table entries should equal nchain; so symbol table indexes also select chain table entries." oh yah.. in an other part of the specs, it says something like this --> The hash table is mandatory when the binary is involving dynamic linking (PT_INTERP) > 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 ? Hmm.. the internet needs securing I think. That is the only possible motivation I'm sure ;-) > mayhem -- Silvio Communicate in total privacy. Get your free encrypted email at https://www.hushmail.com/?l=2 Looking for a good deal on a domain name? http://www.hush.com/partners/offers.cgi?id=domainpeople