Russ Allbery <r...@debian.org>: > Martin Uecker <uec...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140925194743.52fbc006@lemur
