At least part of the problem is that the code runs in a potentially "dirty" state, and has to know every possible thing which has to be "cleaned" from that state (and how to clean it). If it forgets to (or, as was the case here, fails to) remove even one of them, no matter how insignificant it is, it can potentially be exploited.
On the other hand, if the code ran in a "clean" state and only copied things it knew to be safe from the "dirty" state, the risk would be lower (if it forgets or fail to do a copy, the information is simply missing).
In other words, blacklists versus whitelists.
Unfortunately, that cannot be done in this case, since it has no way of knowing which environment variables the called program will need.
Posted Dec 3, 2009 18:25 UTC (Thu) by khc (subscriber, #45209)
[Link]
However, it can make a copy of the environment, with LD_PRELOAD filtered out, and use the new copy.
blacklist vs whitelist
Posted Dec 9, 2009 3:56 UTC (Wed) by pjm (subscriber, #2080)
[Link]
That would be a blacklist approach. The whole point of cesarb's comment is that one would usually prefer a whitelist approach: create a new environment containing just PATH (with a known safe value), HOME, and a couple of others.