Re: Re: Bug#762839: bash without importing shell functions from the environment

[Martin Uecker <uecker@eecs.berkeley.edu>]

Russ Allbery <rra@debian.org>:
> 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.

See the link I posted. This was about shell escaping and fixed
with sanitization of the content in dhclient. But for some reason
it seems it was not applied to all variables, which would have
prevented the present problem for dhcp.

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

Yes, it is a bit difficult to decide what is acceptable and what
not. But environment variables are a huge attack surface because
they are passed on and you have to garantuee that no child process
does something stupid. E.g. some process may dump its complete
environment into a log file and have a buffer overrun there...
Does not seem unlikely to me.

> 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 would say it is problematic because it is not contained but
ends up in a lot of places, i.e. all child processes. One could
at least encode special characters etc... 

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


Martin