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
This archive was generated by hypermail 2b30 : Tue Jun 04 2002 - 18:38:00 PDT