Fixing security issue with lookup returns not tainting the jinja2 environment

CVE-2017-7481

Lookup returns wrap the result in unsafe, however when used through the
standard templar engine, this does not result in the jinja2 environment being
marked as unsafe as a whole. This means the lookup result looses the unsafe
protection and may become simple unicode strings, which can result in bad
things being re-templated.

This also adds a global lookup param and cfg options for lookups to allow
unsafe returns, so users can force the previous (insecure) behavior.
This commit is contained in:
James Cammarata
2017-05-08 10:37:10 -05:00
parent 6f4f7011f1
commit ed56f51f18
4 changed files with 31 additions and 3 deletions

View File

@@ -86,6 +86,20 @@ different locations::
Most users will not need to use this feature. See :doc:`dev_guide/developing_plugins` for more details.
.. _allow_unsafe_lookups:
allow_unsafe_lookups
====================
.. versionadded:: 2.2.3, 2.3.1
When enabled, this option allows lookup plugins (whether used in variables as `{{lookup('foo')}}` or as a loop as `with_foo`) to return data that is **not** marked "unsafe". By default, such data is marked as unsafe to prevent the templating engine from evaluating any jinja2 templating language, as this could represent a security risk.
This option is provided to allow for backwards-compatibility, however users should first consider adding `allow_unsafe=True` to any lookups which may be expected to contain data which may be run through the templating engine later. For example::
{{lookup('pipe', '/path/to/some/command', allow_unsafe=True)}}
.. _allow_world_readable_tmpfiles:
allow_world_readable_tmpfiles