If you're vulnerable to this, then you're vulnerable to someone setting PATH and changing all executables that you refer to.
That's not the "shock" part of "shellshock"; that's a long known issue. Applications which pass arbitrary variables from the network through environment variables already add a unique prefix to the variables, to prevent this kind of problem. That unique prefix also prevents them from accidentally conflicting with the name of an actual executable for this case.
Now, there are still going to be bugs with suid executables not sanitizing their environment, but those apply in many other ways, such as via PATH and LD_PRELOAD.
The "shock" part of shellshock was that it was possible to execute arbitrary code, upon just loading a variable in Bash, regardless of what its name was, depending only on the contents, which in many cases can be attacker controlled.
Exactly. If you are letting an attacker define not just the values of environment variables, but also the names, then you've already lost.
Forget bash. LD_PRELOAD by design lets you load arbitrary code into any child process. Many other environment variables affect libc and other common libraries in arbitrary ways. setuid programs must clear their environment at startup to be safe. Programs like sudo can restore that environment once the user is authorized for root access.
Comments
If you're vulnerable to this, then you're vulnerable to someone setting PATH and changing all executables that you refer to.
That's not the "shock" part of "shellshock"; that's a long known issue. Applications which pass arbitrary variables from the network through environment variables already add a unique prefix to the variables, to prevent this kind of problem. That unique prefix also prevents them from accidentally conflicting with the name of an actual executable for this case.
Now, there are still going to be bugs with suid executables not sanitizing their environment, but those apply in many other ways, such as via PATH and LD_PRELOAD.
The "shock" part of shellshock was that it was possible to execute arbitrary code, upon just loading a variable in Bash, regardless of what its name was, depending only on the contents, which in many cases can be attacker controlled.
Exactly. If you are letting an attacker define not just the values of environment variables, but also the names, then you've already lost.
Forget bash. LD_PRELOAD by design lets you load arbitrary code into any child process. Many other environment variables affect libc and other common libraries in arbitrary ways. setuid programs must clear their environment at startup to be safe. Programs like sudo can restore that environment once the user is authorized for root access.