File paths of ZIP contents are not sanitized

[SLeitgeb]

All files from a package WHL are extracted to the path resolved from the current directory. The ZIP file path is not sanitized first (as suggested in the async_zip package), which could lead to directory traversal attacks, e.g. by a malicious package.

The demo below uses relative filepaths, but this would presumably resolve absolute paths as well (e.g. ~/.cache/uv/archive-v0 + /etc/passwd → /etc/passwd).

Tested on Arch Linux with uv 0.4.28, Python 3.10. This should also affect Windows.

An example of the issue using an empty payload file in a parent directory.

touch payload
uv init payload-package
cd payload-package
uv build
cd dist/
zip payload_package-0.1.0-py3-none-any.whl ../../payload
cd ../..
uv init payload-package-importer
cd payload-package-importer
uv add ../payload-package/dist/payload_package-0.1.0-py3-none-any.whl
ls -1 ~/.cache | grep payload

You should observe a payload file created two directories up relative to the directory from which the paths are resolved (should be the $HOME/.config directory).

[charliermarsh]

Thanks, I'll fix this (though PRs are also welcome).

[BurntSushi]

@SLeitgeb Can you say more about the threat model you're using here?

[SLeitgeb]

The scenario that comes to mind involves a malicious package that would get installed as a user dependency. This package doesn't need to be a direct dependency, it could also be a dependency of another package.

The WHL archive of the malicious package could be manipulated to include arbitrary files (SSH keys, binaries, etc.) that uv would then extract. Running uv as a privileged user in a production environment could then be quite bad.

I don't think this scenario is too likely, and the offending packages would be easy to discover, but there could also be other implications I'm not seeing (maybe package sources outside of pypi?).

[BurntSushi]

I think you also need to stipulate that you've configured uv to never build anything. If you're building sdists, then in that context, arbitrary code can run.

But if you're only installing wheels with --no-build, then yeah, you might have the expectation that builds are isolated from doing these kinds of shenanigans.

[charliermarsh]

Are you sure the example from the summary works? For local wheels, we use the zip crate, not async_zip.

[SLeitgeb]

@BurntSushi That seems right. I don't think it's a big issue, just something I wanted you to be aware of.

[SLeitgeb]

@charliermarsh I tested this several times to be sure, once also with the package installed from a local index, with the same results.

[charliermarsh]

Thanks for catching this @SLeitgeb, appreciate it.