wrongly auxvt in __uClibc_main

[Carmelo AMOROSO]

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 at uclibc.org
> http://lists.busybox.net/mailman/listinfo/uclibc
>