Jinja: Command injection in from_string function (SSTI)
Expected Behavior
The from_string accepts parameters that are not escaped, so an attacker can inject code into the template.
Actual Behavior
Should escape anything passed.
Extra Information and Proof of Concept
https://github.com/JameelNabbo/Jinja2-Code-execution
https://www.exploit-db.com/exploits/46386
mostafa
>All comments
The user who created that repo and CVE doesn't know what they're talking about, and unfortunately now we're going to have to keep addressing it since they irresponsibly notified a bunch of people about a non-issue in an official sounding way. See https://github.com/JameelNabbo/Jinja2-Code-execution/issues/1 for a response to them. I've sent in a request to MITRE to have the CVE invalidated.
Saying Jina has a vulnerability because from_string exists is like saying every dynamic language is vulnerable because eval exists, or every SQL library is vulnerable because they evaluate SQL strings. The issue isn't with those libraries, which all provide proper tools for handling user input. A SQL library doesn't have an injection vulnerability, a project using a SQL library improperly does.
SandboxedEnvironment should be used if you still want to risk compiling untrusted templates, and autoescape should be used when rendering untrusted variables.
davidism
on 18 Feb 2019
Related issues
RickGray
·
6Comments
dwt
·
9Comments
ThiefMaster
·
65Comments
imphil
·
13Comments
harobed
·
6Comments
Most helpful comment
The user who created that repo and CVE doesn't know what they're talking about, and unfortunately now we're going to have to keep addressing it since they irresponsibly notified a bunch of people about a non-issue in an official sounding way. See https://github.com/JameelNabbo/Jinja2-Code-execution/issues/1 for a response to them. I've sent in a request to MITRE to have the CVE invalidated.
Saying Jina has a vulnerability because
from_stringexists is like saying every dynamic language is vulnerable becauseevalexists, or every SQL library is vulnerable because they evaluate SQL strings. The issue isn't with those libraries, which all provide proper tools for handling user input. A SQL library doesn't have an injection vulnerability, a project using a SQL library improperly does.SandboxedEnvironmentshould be used if you still want to risk compiling untrusted templates, andautoescapeshould be used when rendering untrusted variables.