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. 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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- 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/8761gbp1tf....@hope.eyrie.org