wrongly auxvt in __uClibc_main

Rich Felker dalias at aerifal.cx
Mon Nov 26 19:45:06 UTC 2012


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


More information about the uClibc mailing list