On 26/11/2012 20.45, Rich Felker wrote: > 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. >
Hi Rich, > 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 see your concerns, currently I have not a clear idea. > > I don't believe whoever originally added the _dl_unsetenv logic > thought these issues out well... > anyway there is another case that is showing the same issue anyway. If one of the constructor of a dependent shared libraries called the C library unsetenv, the side effect would be the same, that is aux vect invalid if used into the __uClibc_main. Beside the issue with suid programs, also the actual value of the pagesize used by the running kernel could be affected. So I think that there are still more valid reason for redesigning this core piece of code. > Rich Cheers, Carmelo > _______________________________________________ > uClibc mailing list > uClibc@uclibc.org > http://lists.busybox.net/mailman/listinfo/uclibc > _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc