Affected: Homebrew: copier

### 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](https://copier.readthedocs.io/en/stable/configuring/#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](http://github.com/) where the template author can extract the secrets.

Reproducible example:

- Read known file:

```shell echo "s3cr3t" > secret.txt mkdir src/ echo "stolen secret: {{ (_copier_conf.dst_path / '..' / 'secret.txt').resolve().read_text('utf-8') }}" > src/stolen-secret.txt.jinj…

Copier library and CLI app for rendering project templates. Prior to 9.9.1, a safe template can currently read and write arbitrary files because Copier exposes a few pathlib.Path objects in the Jinja context which have unconstrained I/O methods. This effectively renders the security model w.r.t. filesystem access useless. This vulnerability is fixed in 9.9.1.

Affected: PyPI: copier

### 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](https://copier.readthedocs.io/en/stable/configuring/#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](http://github.com/) where the template author can extract the secrets.

Reproducible example:

- Read known file:

```shell echo "s3cr3t" > secret.txt mkdir src/ echo "stolen secret: {{ (_copier_conf.dst_path / '..' / 'secret.txt').resolve().read_text('utf-8') }}" > src/stolen-secret.txt.jinj…

Affected: PyPI: copier

### 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](https://copier.readthedocs.io/en/stable/configuring/#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](http://github.com/) where the template author can extract the secrets.

Reproducible example:

- Read known file:

```shell echo "s3cr3t" > secret.txt mkdir src/ echo "stolen secret: {{ (_copier_conf.dst_path / '..' / 'secret.txt').resolve().read_text('utf-8') }}" > src/stolen-secret.txt.jinj…