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
Created python-jinja2 tracking bugs for this issue: Affects: epel-all [bug 1677655] Affects: fedora-all [bug 1677654]
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/
Here's an issue where they detail that one should not allow untrusted templates without sandboxing. https://github.com/pallets/jinja/issues/549
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.
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.
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.
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?
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.
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.
(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.
Red Hat Satellite 6 is in same situation as other products, so it is also notaffected.
JFTR CVE-2019-8341 is now disputed too.