upvote
Hi! Could you elaborate on the first attack scenario?

> Target: Python package managers using tokio-tar (e.g., uv). An attacker uploads a malicious package to PyPI. The package's outer TAR contains a legitimate pyproject.toml, but the hidden inner TAR contains a malicious one that hijacks the build backend. During package installation, the malicious config overwrites the legitimate one, leading to RCE on developer machines and CI systems.

It seems to imply that you’re already installing a package uploaded by a malicious entity. Is the vulnerable workflow something like “you manually download the package archive, unpack it with system tar, audit all the files and then run uv install, which will see different files”?

reply
Thanks for the question!

Someone could release a malicious package that looks okay to a scanner tool, but when installed using uv can behave differently, allowing attackers to masquerade executable code.

In addition, for OCI images, it is possible to produce an OCI image that can overwrite layers in the tar file, or modify the index. This could be done in a way that is undetectable by the processor of the OCI image. Similar attacks can be done for tools that download libraries, binaries, or source code using the vulnerable parser, making a tar file that when inspected looks fine but when processed by a vulnerable tool, behaves differently.

I hope that answers your question?

reply
So the first scenario is also basically “automatic scanner bypass”? That answers my question, yes.

> making a tar file that when inspected looks fine

Am I correct in understanding that manual inspection would reveal a nested .tar archive (so recursive inspection of nested archives should be enough)?

reply
It is possible to exploit this bug by crafting a file that has tar contents without a header, thus making it hard to detect even with recursive archives.
reply
(this subthread was originally in https://news.ycombinator.com/item?id=45656335 before we merged the threads)
reply
Since this came up specifically for `uv` (i.e. since the Python ecosystem relies on source distributions packaged as .tar.gz): has the Python standard library implementation (which is used by pip) been checked for a similar vulnerability?
reply
It is unlikely to have the bug as it sees more use, but it is worth checking. There have been previous CVEs with Pythons tar module.
reply