Any CGI script which was written in bash, that's the worry. Since mod_cgi uses environment variables to pass along HTTP headers, those programs are sure to touch the environment.
Even if the CGI script is in some other language, think of how many .sh wrapper scripts there are out there.
> This bug only affects people who dont care about security.
And those running code written by people who don't know any better...
If you are an admin for servers running third part code that you have not verified every line of, you need to be concerned about anything like this just in case said code does something that isn't considered best practise.
Also if the CGI code path uses affected functions, you are not going to be protected by avoiding using them in the code that is eventually called.
no, you need to use the exec* family function to start a process without invoking the shell. Take care, it does not really start a new program. It replaces the current executing program. So, you will need to fork beforehand.
Execve, but even that is stretching it, if I write something in Python and someone would tell me "hey use system() or subprocess" I tell them, no thanks, I would rather not do it - then go look for python-way of doing it, if its an image library or whatever it is that needs to be done.
Now you say, but you really really have to run this "utility" with subprocessing or whatever. Well, then its outside of python program and instead of relying on subprocessing Id consider exposing that utility as an interface and writing a small protocl through which the python and utility can exchange data. You most probably have to parse output of utility anyway, better do it right straight away. And if you dont have to parse output of utility - then you send a signal/request/messaging-bus to a listerner which will do what you want - but now with cleaned environment.
All you're doing is hiding the call to system/execve behind deeper layers of abstraction.
Plus if people actually went ahead and reproduced all of the GNU/busybox toolchain inside of Python then everyone would be queuing up to criticise them, particularly if they introduced more security issues (e.g. reproducing rsync fully within a Python library).
Realistically using execve instead of system is a step forward. It is more efficient for non-scripts and you aren't potentially picking up poisoned environmental variables. But if you NEED to run utilities then all you can really do is pre-parse all the parameters carefully and hope for the best.
Suggesting never using either execve or system is just highly unrealistic. There is just too much useful code available via it and aren't nearly enough libraries to reproduce all of that code within whatever language you're working.
> All you're doing is hiding the call to system/execve behind deeper layers of abstraction.
Thats the point, layers where environment variables do not pass - since they in that abstraction do not make sense.
> Plus if people actually went ahead and reproduced all of the GNU/busybox toolchain inside of Python
Basically all of gnu coreutils/busybox, is already inside python, its called import os.
For your rsync example, python-librsync exists. C library, with python binding/interface. No need to run a bash to use the algorithm. If you still want to exec it, then use pythons binding to exceve system call or similar, not to system.
I didnt suggest never to use execve and/or system, I said do not ever use system, sometimes highly questionably use execve.
