On 17/09/2011 11.34, [email protected] wrote: > Actually, I would suggest to make the use of the loader path > optional for the standalone loader too. The less magic, the less > security implications and possible confusion. > > On Fri, Sep 16, 2011 at 11:27:23PM +0200, [email protected] wrote: >> I have found a subtle bug in the corresponding code (besides possible >> unexpected searches depending on the contents of argv[0] and cwd, >> a segfault when argv[0] lacks '/'), a naive fix is as follows: >> (otherwise ignoring argv[0] unless it is an absolute path would be more >> robust) > > ---- > --- ldso/ldso/ldso.c.ori 2011-09-17 10:59:30.000000000 +0200 > +++ ldso/ldso/ldso.c 2011-09-17 11:01:39.000000000 +0200 > @@ -562,23 +562,25 @@ > if (ppnt->p_type == PT_DYNAMIC) { > dpnt = (ElfW(Dyn) *) > DL_RELOC_ADDR(app_tpnt->loadaddr, ppnt->p_vaddr); > _dl_parse_dynamic_info(dpnt, > app_tpnt->dynamic_info, debug_addr, app_tpnt->loadaddr); > } > } > > +#ifdef __LDSO_SEARCH_INTERP_PATH__ > /* Store the path where the shared lib loader was found > * for later use > */ > _dl_ldsopath = _dl_strdup(tpnt->libname); > ptmp = _dl_strrchr(_dl_ldsopath, '/'); > if (ptmp && ptmp != _dl_ldsopath) > *ptmp = '\0'; /* leaking some string memory */ > else > _dl_ldsopath = NULL; /* leaking the whole string > memory */ > > _dl_debug_early("Lib Loader: (%x) %s\n", (unsigned) > DL_LOADADDR_BASE(tpnt->loadaddr), tpnt->libname); > +#endif > } else { > #endif > > /* At this point we are now free to examine the user application, > * and figure out which libraries are supposed to be called. Until > * we have this list, we will not be completely ready for dynamic > ---- > > Cheers, > Rune > >
Hi Rune, reading it again, in the security context, indeed it could be useful to avoid loading libraries from the directory of the customized ld.so. By default this option should be enabled, but on an hardened system, it could be disabled... something as we have already done for LD_PRELOAD for example. I'll consider to write a proper patch for this. Thanks for the hint. Carmelo _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
