5 ms·

One example: If a server script calls system(), it actually pops up a shell to execute the command.

by nikital 12y ago

antocv 12y ago
Which has not been standard security practice for last 20 years - Do Not Use System or Execve or any other stuff from your php/web-scripts. Not. Ever. This bug only affects people who dont care about security.
- hadoukenio 12y ago
  Serious question - how do you run utility programs to do things without system()?
  - mborch 12y ago
    Run the program without starting a shell?
    - hadoukenio 12y ago
      This is exactly what system() does.
      - noselasd 12y ago
        No, system() uses /bin/sh to run the program.
        camperman 12y ago
        Which is symbolically linked to /bin/bash on many of my systems.
      - malka 12y ago
        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.
  - mborch 12y ago
    http://linux.die.net/man/3/execv http://linux.die.net/man/3/execv
  - antocv 12y ago
    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.
    - mkesper 12y ago
      The standard way of doing things in Python is to use subprocess __without__ Shell. https://docs.python.org/3.4/library/subprocess.html#security-considerations https://docs.python.org/3.4/library/subprocess.html#security...
    - UnoriginalGuy 12y ago
      That "solution" won't protect you from this. 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.
      - antocv 12y ago
        > 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.
- dspillett 12y ago
  > 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.

One example: If a server script calls system(), it actually pops up a shell to execute the command.

by nikital 12y ago

One example: If a server script calls system(), it actually pops up a shell to execute the command.

Which has not been standard security practice for last 20 years - Do Not Use System or Execve or any other stuff from your php/web-scripts. Not. Ever. This bug only affects people who dont care about security.

hadoukenio 12y ago
Serious question - how do you run utility programs to do things without system()?
- mborch 12y ago
  Run the program without starting a shell?
  - hadoukenio 12y ago
    This is exactly what system() does.
    - noselasd 12y ago
      No, system() uses /bin/sh to run the program.
      - camperman 12y ago
        Which is symbolically linked to /bin/bash on many of my systems.
    - malka 12y ago
      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.
- mborch 12y ago
  http://linux.die.net/man/3/execv http://linux.die.net/man/3/execv
- antocv 12y ago
  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.
  - mkesper 12y ago
    The standard way of doing things in Python is to use subprocess __without__ Shell. https://docs.python.org/3.4/library/subprocess.html#security-considerations https://docs.python.org/3.4/library/subprocess.html#security...
  - UnoriginalGuy 12y ago
    That "solution" won't protect you from this. 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.
    - antocv 12y ago
      > 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.
dspillett 12y ago
> 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.