Bug 1677653 (CVE-2019-8341) - CVE-2019-8341 python-jinja2: command injection in function from_string
Summary: CVE-2019-8341 python-jinja2: command injection in function from_string
Keywords:
Status: CLOSED NOTABUG
Alias: CVE-2019-8341
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1677654 1677655
Blocks: 1677659
TreeView+ depends on / blocked
 
Reported: 2019-02-15 13:46 UTC by Dhananjay Arunesh
Modified: 2019-09-29 15:08 UTC (History)
32 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-06-10 10:48:04 UTC


Attachments (Terms of Use)

Description Dhananjay Arunesh 2019-02-15 13:46:30 UTC
An issue was discovered in Jinja2 2.10. The from_string function is prone to Server Side Template Injection (SSTI) where it takes the "source" parameter as a template object, renders it, and then returns it. The attacker can exploit it with {{INJECTION COMMANDS}} in a URI.

Reference:
https://github.com/JameelNabbo/Jinja2-Code-execution

Comment 1 Dhananjay Arunesh 2019-02-15 13:46:45 UTC
Created python-jinja2 tracking bugs for this issue:

Affects: epel-all [bug 1677655]
Affects: fedora-all [bug 1677654]

Comment 2 Scott Gayou 2019-02-15 14:28:58 UTC
After a quick glance, this CVE doesn't seem valid. If you let a user inject data into an unsafe function, they can do unsafe operations. I'm trying to find this documented in jinja2. They do support sandboxing, so it seems like they're aware of it.

http://jinja.pocoo.org/docs/2.10/sandbox/

Comment 3 Scott Gayou 2019-02-15 14:30:52 UTC
Here's an issue where they detail that one should not allow untrusted templates without sandboxing.

https://github.com/pallets/jinja/issues/549

Comment 4 Adrian 2019-02-15 14:38:30 UTC
I'm one of the maintainers of the Pallets projects, including Jinja.

This CVE is a bad joke. It's like claiming eval() in the Python stdlib is insecure because it executes code.
Jinja templates should never be loaded from untrusted sources.

So nothing should be done here, there is literally nothing to be fixed.

Comment 5 Scott Gayou 2019-02-15 15:02:05 UTC
Thanks Adrian, that was my guess. If you're upstream, you can submit a reject request to MITRE and they will mark the CVE as invalid.

Comment 7 Salvatore Bonaccorso 2019-02-15 19:54:23 UTC
For asking for the REJECT, please use the webform at https://cveform.mitre.org/ -> Request an update to an existing CVE entry -> Type of update requested -> Rejection.

Comment 8 David Lord 2019-02-18 05:30:01 UTC
I'm another Pallets/Jinja maintainer. I sent in a request on 2/15, I'm not sure what the response time is. The whole process is somewhat opaque, and the fact that someone could report this without any validation is problematic to begin with. We've already had people ping us about it.

Is there any way Red Hat can invalidate the linked CVE in their db, or is that all just a view on the MITRE db?

Comment 9 Scott Gayou 2019-02-18 13:36:07 UTC
Statement:

Red Hat Product Security does not believe this CVE assignment is valid. To the best of our knowledge, Jinja2 does not make any guarantees about being able to safely handle untrusted data by default without sandboxing modes enabled.

Comment 10 Scott Gayou 2019-02-18 14:30:17 UTC
I added a statement with our current understanding of the issue. Best course of action is to wait for the reject I think. I remember MITRE taking several days in the past for a similar operation.

Does your documentation have any clear guidelines or recommendations on not allowing user-input in the unsandboxed (default?) mode? While that may be obvious to us, it could help more novice users avoid that mistake, and would also be an excellent place you could point to when trying to fend off spurious CVE assignments in the future. "secure with the optional sandboxed template execution environment" definitely points to it, but maybe a FAQ entry could help?

Possible I missed it (please link if so, I'll add it to my notes!).

Cheers.

Comment 11 Andrej Nemec 2019-02-19 08:22:19 UTC
(In reply to David Lord from comment #8)
> I'm another Pallets/Jinja maintainer. I sent in a request on 2/15, I'm not
> sure what the response time is. The whole process is somewhat opaque, and
> the fact that someone could report this without any validation is
> problematic to begin with. We've already had people ping us about it.
> 
> Is there any way Red Hat can invalidate the linked CVE in their db, or is
> that all just a view on the MITRE db?

Hi David,

Unfortunately, the rejection can only be done by Mitre. Red Hat has no way to edit / update their CVE database for CVEs they assigned.

Comment 12 Richard Maciel Costa 2019-03-14 23:53:02 UTC
Red Hat Satellite 6 is in same situation as other products, so it is also notaffected.

Comment 13 Leonardo Taccari 2019-08-06 16:30:39 UTC
JFTR CVE-2019-8341 is now disputed too.


Note You need to log in before you can comment on or make changes to this bug.