Vulnerable Python code is not detected by CWE-094 rule

[ogipierogi]

Description of the issue
I am trying to simulate Python code findings using an example vulnerable code:

compute = input('\nYour expression? => ')
if not compute:
    print ("No input")
else:
    print ("Result =", eval(compute))

which can be exploited e.g. using input:

__import__('os').system('ls -al /')

I also used code directly from the https://codeql.github.com/codeql-query-help/python/py-code-injection/ to check if there issue is detected by CodeQL, but it simply does not identify this code as a vulnerable for code injections.
Environment:

Python version 3.9.2
Python extractor version 5.35
CodeQL command-line toolchain release 2.14.5.

Partial logs (no other warnings or errors/failures):

Loaded /codeql/qlpacks/codeql/python-queries/0.8.4/Security/CWE-094/CodeInjection.qlx.
Starting evaluation of codeql/python-queries/Security/CWE-094/CodeInjection.ql.
[25/46 eval 19s] Evaluation done; writing results to codeql/python-queries/Security/CWE-094/CodeInjection.bqrs.

Other vulnerable code snippet which is detected by CodeQL:

from flask import app

@app.route('/')
def execute_input_noncompliant():
    from flask import request
    module_version = request.args.get("module_version")
    # Noncompliant: executes unsanitized inputs.
    exec("import urllib%s as urllib" % module_version)

[mbg]

Hey @ogipierogi 👋🏻 thank you for reporting this! I can confirm that I also don't get any results for the sample code you have provided. Looking at the implementation of the query, it doesn't look like input is currently treated as a taint source here. Your potential attack makes sense to me, so I have passed this on to our Python team.

[tausbn]

I think the issue here is that input is not vulnerable under Python 3 (which is what we assume by default).

Compare and contrast the Python 3 docs with the corresponding Python 2 docs. In Python 3, there is no eval, and hence no vulnerability.

We have a query for detecting uses of input, but it only flags such uses if the analysis has been instructed to interpret the code as being Python 2 code.

[tausbn]

Ah, sorry. I misinterpreted the issue slightly. I think the main reason we don't consider input to be a source of user-controlled input is that if you're in a situation where an untrusted user is already running a program on the machine, then it's likely already game over. In other words, input is so local that it's assumed to be safe. (That being said, if you have examples of this being exploited in the wild, it would be easy to add input as a source of tainted input.)

[smelc]

Thanks @tausbn for the explanation, I ran into the same problem as the author, assuming that input is unsafe and was modeled somewhere, but couldn't find it in the standard library.

Now I know it's not modeled. A bit surprising but why not 🙂

[tausbn]

Actually, these days you can get the behaviour you desire, by setting the threat model correctly. For instance, if you set it to local, then things like input, raw_input, and sys.stdin will be considered as sources of user-controlled input (as well as many other instances of "local" input).

Given that we now have a solution to the original issue, I'll go ahead and close this issue. Feel free to reopen if you have questions that cannot be answered by the documentation. 🙂

[smelc]

Oh nice, thanks for pointing out threat models @tausbn, I didn't know about them ❤