NOEXEC environment bug

[Ralf Friedl]

Jack Schmidt wrote:
>> On 2017-11-02, at 08:26 , Denys Vlasenko <vda.linux at googlemail.com> wrote:
>>
>> On Wed, Nov 1, 2017 at 2:28 AM, Jack Schmidt <busybox at mowsey.org> wrote:
>>> I believe I have found a bug in the current version of busybox.
>>>
>>> When:
>>> * an applet is marked NOEXEC,
>>> * busybox is configured with CONFIG_FEATURE_SH_STANDALONE=y, and
>>> * busybox's ash is asked to do "ENV_VAR=newval no_exec_app"
>>> Then the no_exec app is not called with the new environment.
>>>
>>> This affects git master d5c1482fbac71c51e3add52632cdf1f9f9e6661b and 1:1.21.0-1ubuntu1
>>>
>>> To reproduce from git (on linux):
>>>
>>> git pull
>>> make defconfig
>>> sed -i 's/# CONFIG_FEATURE_SH_STANDALONE is not set/CONFIG_FEATURE_SH_STANDALONE=y/' .config
>>> make
>>> ./busybox ash -c 'BUG=1 head /proc/self/environ | grep -q BUG && echo ok || echo bug'
>>> ./busybox ash -c 'BUG=1 ./busybox head /proc/self/environ | grep -q BUG && echo ok || echo bug'
>>>
>>> The first echoes "bug" because the environment is not set.
>> I reproduced this.
>>
>> The problem here is that /proc/self/environ is not the environment
>> as seen by C code. It is the memory area of the process where *initial
>> environment
>> variables* are stored (IIRC it is located in the top part of the stack area).
>>
>> When NOEXEC applet is executed, the environment *is* set up correctly,
>> but on the C
>> language level: environ[] array is updated. The *initial environment*
>> is not updated.
>> Therefore, /proc/self/environ does not show new added variables.
> Thanks, that makes sense and seems hard to fix, especially portably.
There is nothing portable in /proc/self/environ, or anywhere in the 
/proc directory. /proc/self/environ is for the benefit of programs like 
ps. It is only possible to overwrite it in place, which is mainly done 
for passwords and other sensitive information. You would have the same 
problem with /proc/self/cmdline.
>>> Alpine linux uses a similar command to check if /proc is really mounted, or is just a semi-convincing fake. With CONFIG_FEATURE_SH_STANDALONE, real /proc registers as a fake.
Why is such a check necessary? Why would someone want to mount a fake 
when it is easier to mount the real proc? And if it was done 
intentionally, why try to detect it?