On Mon, Nov 26, 2012 at 04:45:18PM +0100, Filippo ARCIDIACONO wrote: > Folks, > we have seen some issues recently in uClibc related to the way the > aux vect is managed inside __uClibc_main. > > Running a set-[user,group]-ID ELF binaries with some 'unsecure' > environment variable set (i.e LD_LIBRARY_PATH or LD_PRELOAD), auxvt > is wrongly set in __uClibc_main. > > The problem is caused by the call to _dl_unsetenv function in ldso.c > that pops the specific env variables > from the stack adding a corresponding number of NULL entries at the > end of the environments stack.
I don't know if anybody wants to tackle this, but I believe the current _dl_unsetenv behavior is non-conforming (the implementation does not have a license to unset environment variables at will). The correct behavior is just ignoring the variables in the current (suid) process, but still making them available to the application which might want to query them with getenv or pass them on to child processes. There is some concern about the safety of the latter, but the issue only arises if the suid program has elevated itself to having both read and effective uid privileged. If the real/effective ids still differ, the child will ignore the environment variables, and if they process has fully dropped privileges down to that of the invoking user (the original real uid), then it's appropriate that the environment variables be honored. I don't believe whoever originally added the _dl_unsetenv logic thought these issues out well... Rich _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc