Unsafe string escaping throughout main script #6463
Description
A double-quote in a value would allow executable code to be passed to python:
Line 1828 in 52e051b
Values concatenated in JSON as-is, without escaping. Many are okay because the inputs are known not to contain special characters, but others should be treated as untrusted user-input. Single quoting would aid readability, too, e.g. _djson='{"status":"deactivated"}' instead of _djson="{\"status\":\"deactivated\"}".
Line 3818 in 52e051b
Generating other shell scripts without escaping the content of the variables:
Line 6125 in 52e051b
The above should be more like below, with
$lesh having its unnecessary extra quotes removed from its assignment on line 6076, and cron lines need escaping of % characters as well:
lesh=$LE_WORKING_DIR/$PROJECT_ENTRY
...
_c_entry=' --config-home '$(printf '%q' "$_c_home")
...
echo "$random_minute $random_hour * * * $(printf '%q' "$lesh") --cron --home $(printf '%q' "$LE_WORKING_DIR")$_c_entry > /dev/null" | sed 's/%/\\%/g'More of the latter in env file creation, where every item sent to _setopt seems to be "escaped" by surrounding in quotes in the call, rather than passing the value as-is, and having that function escape the output correctly:
Line 6558 in 52e051b
And profile modification:
Line 6570 in 52e051b
Many instances can be found by search for the literal string \", where the code assumes values will contain no quotes or other escape sequences that are valid in the resultant double-quoted string literal. Some are false positives in informational output.
A function like this would make most less repetitive, the newline deliberately added because $() will trim it.:
_esc () {
printf '%q\n' "$1"
}Used as the printf above:
echo "var=$(_esc "$var")" > some-scriptI understand it's not an easy fix, as the different environments and programs will need different escaping rules.