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”?
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.
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?
Package management systems are scary before packages are abandoned too. Your production infrastructure is trusting some random developer/s to both do the right thing and not get hacked.
That’s not to say oss cannot be trusted, but it certainly makes trusting smaller projects and packages scary.
I triaged this vulnerability from Astral's side, so I wanted to make a clarificatory point that's also present in the advisory[1]: parser differentials can be extremely bad, but the risk to the Python ecosystem in this particular case is moderated by the fact that tar is only used with source distributions, which already possess arbitrary code execution at resolution/install time by design.
In other words: this is an obfuscation vector within Python packaging, but it doesn't grant the attacker a novel privilege.
(This doesn't detract from the overall severity of the bug itself: there are plenty of ecosystems and contexts where this is a serious issue, and there's no easy way to assert that they aren't affected by the bug in this family of async-tar packages. Edera has done an excellent job of highlighting this, and I thank them for their disclosure!)
Hi! I’m the CTO of Edera and discovered this bug with my colleague Steven!
The story of this bug is interesting. We were both up late at night working on GPU support on the Edera platform, and we had just pulled an NVIDIA container image. What should have resulted in a temporary directory of tar files for OCI layers was filled with NVIDIA library files! We were both super confused until I had an “oh god no” moment and realized this happened.
We kicked right into action on responsible disclosure.
I can answer any questions, but I want to send a huge thank you to our team for working together on this and to Astral for being wonderful to work with!
Why does TAR even have nested archives? I though bare TAR is very simple format, now apparently there is some nested crap in there... oh the format overengineering.
15 comments
[ 190 ms ] story [ 398 ms ] thread> 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”?
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?
That’s not to say oss cannot be trusted, but it certainly makes trusting smaller projects and packages scary.
In other words: this is an obfuscation vector within Python packaging, but it doesn't grant the attacker a novel privilege.
(This doesn't detract from the overall severity of the bug itself: there are plenty of ecosystems and contexts where this is a serious issue, and there's no easy way to assert that they aren't affected by the bug in this family of async-tar packages. Edera has done an excellent job of highlighting this, and I thank them for their disclosure!)
[1]: https://github.com/astral-sh/tokio-tar/security/advisories/G...
The story of this bug is interesting. We were both up late at night working on GPU support on the Edera platform, and we had just pulled an NVIDIA container image. What should have resulted in a temporary directory of tar files for OCI layers was filled with NVIDIA library files! We were both super confused until I had an “oh god no” moment and realized this happened.
We kicked right into action on responsible disclosure.
I can answer any questions, but I want to send a huge thank you to our team for working together on this and to Astral for being wonderful to work with!
And where is the RCE part ?