CLI application running user defined command periodically [closed]

Question

For a toy CLI application I'm writing, I'd like to store a string with an user defined command that will be executed periodically (like shell -c <command_string>).

I have seen other applications do this, for example in fzf you can set an environment variable with a command to be executed every time the application runs.

I'm worried about an attacker being able to modify this string with something malicious, but I don't know if my concern is justified: if the attacker is able to modify this string, maybe it already has access to the user's system.

The string with the command will be stored in a SQLite database along with other application data. (I'm aware that I have to take measures when I store the data to avoid SQL injection)

Answer 1

This boils down to a core question:

• Is sh a valid command?

If so, then the user already has access; there is nothing further to contemplate in the question as-stated; a "malicious" user will have just as much access as a "non-malicious" and you should go to a regular threat model for potentially-malicious logged-in users, such as sandboxing.

If not, then you really ought to:

1. Set up a whitelist of permitted commands
2. Ensure you are sanitizing (or, better-yet, parameterizing) user input appropriately
   • example: if your toy CLI application is a Python program—

     def handle_user_input(untrusted_string: str):
         user_command = shlex.split(untrusted_string) #: list
         if not user_command[0] in whitelist:
            raise ValueError("Non-whitelisted command.")
         store_command(user_command)
     
     def event_callback(user_command: list):
         """Is called on the parameterized, whitelist-checked user_command list every interval"""
         assert isinstance(user_command, list)
         assert user_command[0] in whitelist
         subprocess.run(user_command)
     

3. Consider contingencies for when one of the whitelisted programs has a shell-execution vulnerability anyway, and this use-case reduces to what where sh is allowed (i.e.: sanbox the user.)

Your threat-model is poorly-defined in the question as-stated, but I hope this helps.

---

Also, check out this answer on another question — he expresses much better what I've tried to communicate here.

Allowing them to "run a command" is tantamount to letting them log in (after all, that's what "logging in" gates in the first place.)