Warn about Code Execution in Arithmetic Expressions for Bash [[ $1 -eq 42 ]]

[clushie]

Blog posts discussing this issue:

• Some surprising code execution sources in bash
  • Discussion with further clarifications.
• Bash’s white collar eval: [[ $var -eq 42 ]] runs arbitrary code too
• Related issues/duplicates:
  • Shellcheck doesn't always warn of unsafe array subscript expansions in arithmetic context #1322
  • Warn about the use of unvalidated input in arithmetic contexts. #2679

For new checks and feature suggestions

• https://www.shellcheck.net/ (i.e. the latest commit) currently gives no useful warnings about this
• I searched through https://github.com/koalaman/shellcheck/issues and didn't find anything related

Here's a snippet or screenshot that shows the problem:

• test.sh

#!/usr/bin/env bash
echo "integer comparison with quoted: ${1}"

if [[ "${1}" -eq 42 ]]
then
  echo "Correct"
else
  echo "Wrong"
fi

echo 'a[$(head -1 /etc/passwd)] + 42'
./test.sh 'a[$(head -1 /etc/passwd)] + 42'

The shell evaluates values in an arithmetic context in several syntax constructs where the shell expects an integer. This includes: $((here)), ((here)), ${var:here:here}, ${var[here]}, var[here]=.. and on either side of any [[ numerical comparator like -eq, -gt, -le and friends.

Also affected

• foo="${untrusted_input}"; (( foo > 10 ))

Here's what shellcheck currently says:

• "$?" = 0 aka no issues

Here's what I wanted or expected to see:

• [[ ]] with Arithmetic Expressions is insecure and can yield to code execution, use [ ] instead.

[vimpostor]

This is also (part of the) bullet point 7 from the famous BashPitfalls, which confirms that the only safe alternative is using [ ]:

If the contents of $foo are not sanitised and are out of your control (if for instance they're coming from an external source), then all but [ "$foo" -gt 7 ] constitute an arbitrary command injection vulnerability as the contents of $foo are interpreted as an arithmetic expression

There also is a short Bash mailing list thread from 2014 where this was discussed, but ultimately not fixed.

Here is an example incident from 2020 where this was used to run arbitrary shell commands and I expect more undiscovered CVEs out there, as practically noone knows about this problem.

I think this issue is also more a duplicate of #2679.