Re: Bug#762839: bash without importing shell functions from the environment
Martin Uecker <uecker@eecs.berkeley.edu> writes:
> While everybody is looking at bash, isn't this the real the injection
> part? Why are there still programs which copy stuff from the network
> into environment without proper sanitation?
The previous sanitization for environment variables mostly focused on not
letting the client set arbitrary environment variables and instead tightly
restricting which variables could be set. The problem with this
vulnerability is that the varible doesn't matter, only the value, which is
a new type of problem.
Also, prior to the discovery of this bug, I'm dubious that anyone would
have found this particular environment variable pattern all that
concerning. It's not obvious why it would be an issue. So only a pure
whitelisting approach on environment variable *contents* would have been
effective, and it's hard to define what language you want to restrict the
contents to.
It's very useful in some web situations to get access to arbitrary client
data via environment variables. I sometimes want *exactly* what the
client sent as its Browser string, for instance, metacharacters and all.
I should be able to get that as an environment variable and process it;
there's no obvious reason to believe that should be unsafe. I think
assuming the mere contents of an environment variable restricted to a
namespace like HTTP_* and kept well away from, say, LD_* would not be
interpreted as executable code is pretty reasonable.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: