NOEXEC environment bug

Denys Vlasenko vda.linux at googlemail.com
Thu Nov 2 12:26:01 UTC 2017


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.

> 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.

Please tell me more. What exactly Alpine is doing.


More information about the busybox mailing list