In certain CLI modules, there are scenarios that need to call a subprocess to run commands outside CLI, like getting kubectl info in aks, or deployment setup in mysql using git
and gh
, through python built-in subprocess module. Despite its simplicity and versatility, ensuring the security of applying it can be challenging in different platforms under different circumstance, and it is error-prone for developers to neglect security best practices during development.
Assume a script that needs to read in user_input
from users to execute a git
related command and runs it through subprocess using shell. In regular cases, users would add a valid git command, like git --version
or something else, but if undesired input gets logged into this system, like --version;echo aa
, the appended ;echo aa
would be executed by subprocess
too, like below:
import subprocess
user_input = input("input a git command to run: ")
cmd = f"git {user_input}"
subprocess.run(cmd, shell=True)
input a git command to run: --version;echo aa
git version 2.34.1
aa
This is a simple example for demonstrating the side effects in python's subprocess
improper usage. And it's common for CLI developers to build and execute commands dynamically from users' input in a more complicated way. When constructing and executing commands in subprocess through shell=True
, it exposes a big security vulnerability to potential malicious users outside.
There are several aspects of security practices that developers need to have in mindset to safeguard their CLI modules from command injection attacks.
Azure CLI provides a centralized function run_cmd
adapted from official subprocess.run
, with necessary argument covered and illegal input blocking enforced.
What developers need to do is:
from azure.cli.core.util import run_cmd
- replace
subprocess.run
(orPopen
orcheck_call
orcheck_output
orcall
) withrun_cmd
. - construct cmd
args
as array, like[executable, arg0, arg1, arg2, ...]
run_cmd
will add necessary argument type checks and process the input and output the same way as subprocess.run
, and block potential risks from commands constructed from user input.
Below is an example for run_cmd
use case:
# code before:
cmd = f"git commit -m {user_message}"
import subprocess
output = subprocess.run(cmd, shell=True, check=False, stderr=subprocess.PIPE, stdout=subprocess.PIPE)
if output.returncode != 0:
raise CLIInternalError('Command execution failed, command is: '{}', error message is: {}'.format(cmd, output.stderr))
return output.stdout
If run_cmd
is applied, it would be like:
# code after:
cmd = ["git","commit", "-m", user_message]
import subprocess
from azure.cli.core.util import run_cmd
output = run_cmd(cmd, check=False, capture_output=True)
if output.returncode != 0:
raise CLIInternalError('Command execution failed, command is: '{}', error message is: {}'.format(cmd, output.stderr))
return output.stdout
All various kinds of subprocess
Popen calling use cases can be easily adjusted into run_cmd
with security risks processed and eliminated in this centralized function.
Besides that, users might need to know some parts of the accessibility in both run_cmd
and subprocess
- when calling shell built-in cmds, like
dir
orecho
, usingshell=True
in windows platform,subprocess
implicitly usescmd.exe
, whilerun_cmd
asks developers to provide thecmd.exe
as executable file specifically in the arg list's first item, like["cmd.exe", "/c", "echo", "abc"]
- if developers want to find an easy way to split their current cmd string into list, for unix-like platforms, developers can apply
shlex.split
for quick access. But a prepared cmd statement is still more recommended (for more info about prepared cmd statement, please read below sections). - if developers want to locate the target command's executable file, a tool developers can use is
shutil.which
that gives the full executable file path in system, likeshutil.which(git)
returns the fullgit.exe
path in windows platformC:\\Program Files\\Git\\cmd\\git.EXE
. - if the target cmd is
az
-related, likeaz group show --name xxxx
, please use internal corresponding function callcli_ctx.invoke(["az", "group", "show", "--name", "xxx"])
to get the target information.
The following sections discuss some secure coding conventions that, when implemented, can help protect CLI applications from command injection vulnerabilities when calling subsystems through subprocess
.
Input from users or external sources should never be trusted when appending them into subprocess
cmd. Developers better provide expected patterns to validate and sanitize user input before adding that into subprocess' cmd.
Below is an example input sanitizer that only allows alphanumeric characters from the input string.
import re
def sanitize_input(user_input):
return re.sub(r'[^a-zA-Z0-9]', '', user_input)
In a real CLI module scenario, developers better use their corresponding sanitization pattern for reducing the chaining commands risks.
A parameterized cmd statement is a way to structure a command starting from defining the command structure first and then provide the parameters that should be inserted into the command separately. In this way, the system will treat the first item as the executable file and the left item as args of that executable application.
# instead of
cmd = f"git {user_input}"
# using
cmd = ["git", user_input]
When using subprocess module, avoid shell=True
argument when it comes with cmd containing user inputs. When python executes a command with shell=True
, the system shell will interpret any string passed in and if this string contains user input without proper sanitization, an attacker can inject malicious commands, as demonstrated in the very beginning of this doc.
Ensuring the safety of Azure CLI from command injection under subprocess calling requires an in-depth understanding of these vulnerabilities and also proactive measures to counteract potential exploits. CLI developers can apply the three security practices, if applicable, when using builtin subprocess
, but it's recommended to use the centralized function run_cmd
CLI provided, to safeguard CLI modules from command injection attack and for future more accessible security enforcements.