6 ms·

Tarmageddon: RCE vulnerability highlights challenges of open source abandonware

98 points by vsgherzi 1y ago

denhamparry 1y ago
I'm from Edera. If you have any questions please send them our way
- goldsteinq 1y ago
  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”?
  - denhamparry 1y ago
    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?
    - goldsteinq 1y ago
      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)?
      - denhamparry 1y ago
        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.
- dang 1y ago
  (this subthread was originally in https://news.ycombinator.com/item?id=45656335 https://news.ycombinator.com/item?id=45656335 before we merged the threads)
- zahlman 1y ago
  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?
  - denhamparry 1y ago
    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.
TealBLAHAJ 1y ago
The scary part isn’t the bug — it’s how fragile the patching process becomes once a crate goes unmaintained.
- hsbauauvhabzb 1y ago
  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.
  - cozzyd 1y ago
    In principle "traditional" curated Linux distro package systems will patch stuff even if upstream is unresponsive.
    - hsbauauvhabzb 1y ago
      Sorry I should have clarified that I was referring to language based systems (cargo, pip, npm, etc). But you do raise a good point, it’s less about the concept of package management and more around the point of curation and central security guarantees / policies / procedures. In theory RHEL package management system could have similar problems to cargo or npm, but they are much better funded and thus managed.
    - ajross 1y ago
      In practice, not principle. Virtually every non-trivial upstream package in debian/fedora/arch/whatever has at least a handful of distro-specific patches. Sometimes they're just configuration, sometimes they're distro-maintained security fixes, etc... But people exercise those features regularly and distros are not shy about maintaining software. It's a very different world from "We Just Ship What They Give Us" in npm/cargo/etc...
  - BobbyTables2 1y ago
    I really hate it when various packages expect users to add their custom repo. Especially for something where I don’t care about updates. Feels like every little thing should be in its own docker container with limited filesystem access. Of course that is a whole lot of trouble… The dependency trees in cargo/pip also greatly bother me. VS Code extensions are also under appreciated. Some turd makes a “starter pack” for rust/python/etc with a great set of common extensions… plus a few that nobody has heard of… Over time, they reach 50k-100k downloads and start to appear legit… Excellent way to exfiltrate trade secrets!!!
arresin 1y ago
From my experience abandoned repos is common in rust. Why is this?
- hunterpayne 1y ago
  I suspect because a lot of Rust library projects are just clones of a project (usually in C) translated to Rust. This is a good way to learn Rust. However, after you learn it, why maintain it? There isn't really much incentive. Add to that the politics of the Rust ecosystem and it causes churn in the dev population. I suspect there are other reasons too. There is a cost to fad languages being used. Replicating the ecosystem of libraries around a language is a huge job. Its rare that a language ever gets the same size and quality ecosystem as say C or Java. But the fans of the language will try. This leads to a lot of ported projects and a small number of devs maintaining a huge number of projects. That's a recipe for abandonware. I suspect a lot of student projects too which is also likely to do the same.
- aDyslecticCrow 1y ago
  I personally suspect it's an effect of the over reliance of the package manager approach to software development that rust and a few other languages use, which itself is an unintended to consequence of a well designed library import system. Languages where importing a library is hard, libraries tend to grow quite large. Large libraries have larger backing, more established development and security protocols. When OpenCV, TinyUSB, Numpy, nimBLE start to struggle, it's easier to notice and companies relying on them may step up to fork, maintain of fund its continued use. Languages where importing and creating a library is easy, we see small atomic packages for small utility programs, over large libraries. This spreads the software supply-chain wider, into smaller teams of maintainers. If the same amount of code is fractured over 50 small libraries maintained by 1-3 people each, the likelihood of one or two becoming abandoned grows. I've been a bit weary about the dependency and package manager approach more modern languages use. It trades convenience for some pretty scary supply-chain attacks.
  - normie3000 1y ago
    I haven't seen this perspective before but it's a very elegant explanation for why e.g. npm is so much scarier than maven. I wonder if safety could be improved a little if private package management was easier than throwing things out in public.
jedisct1 1y ago
The state of the Rust crates ecosystem https://00f.net/2025/10/17/state-of-the-rust-ecosystem/ https://00f.net/2025/10/17/state-of-the-rust-ecosystem/
- huflungdung 1y ago
  [dead]
woodruffw 1y ago
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!) [1]: https://github.com/astral-sh/tokio-tar/security/advisories/GHSA-j5gw-2vrg-8fgx https://github.com/astral-sh/tokio-tar/security/advisories/G...
greatgib 1y ago
I'm so confused, I was thinking that we were rewriting everything from C to Rust because Rust was a "safe language" preventing vulnerabilities...
- woodruffw 1y ago
  To the best of my knowledge, nobody has ever seriously claimed that Rust (or any other general purpose programming language) can fully prevent logic errors. Rust's advantage is that it can prevent logic errors from becoming memory safety vulnerabilities (and separately, its type system makes some - but not all - classes of logic errors more difficult to introduce).
- ajross 1y ago
  This doesn't appear to be a memory safety bug. It's a data handling error, and the "RCE" in question is that the tar code can be fooled by a malicious tarball into writing files with arbitrary permissions at arbitrary paths (which is... actually something all tarballs can do, so I'm not really following why this is being treated as severe). But to your point: yes, it's a good example about how security bugs live at all layers of the stack and that being checked against memory corruption does nothing to prevent you from writing bugs in the semantic space.
  - SoftTalker 1y ago
    iow it's a bug that can corrupt your data, but it does it safely.
- kobebrookskC3 1y ago
  if it was in c, who knows how many memory corruption bugs would be found before they stumbled upon this...
  - whatevaa 1y ago
    If it was C, 99% it would have been an code execution.
  - 1y ago
lvass 1y ago
Why didn't crates.io maintainers apply the patch themselves? NPM does meddle with packages when an incident happens like they did with left-pad.
- woodruffw 1y ago
  I think that would be pretty disruptive, and would break some assumptions around crate integrity that are deeply held. My understanding is that the left-pad incident is not directly analogous, since it involved restoring a deleted package rather than modifying an extant package.
- eviks 1y ago
  Do you have a more relevant example of meddling besides a binary block/publish?
alexzenla 1y ago
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!
whatevaa 1y ago
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.
- __s 1y ago
  Not inherent to format. Issue is just header parser ends up reading file contents, so putting tar file as file contents confuses things It'd be like putting zip in zip
hulitu 1y ago
> Tarmageddon: RCE vulnerability highlights challenges of open source abandonware And where is the RCE part ?

98 points by vsgherzi 1y ago

denhamparry 1y ago

I'm from Edera. If you have any questions please send them our way

goldsteinq 1y ago
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”?
- denhamparry 1y ago
  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?
  - goldsteinq 1y ago
    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)?
    - denhamparry 1y ago
      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.
dang 1y ago
(this subthread was originally in https://news.ycombinator.com/item?id=45656335 https://news.ycombinator.com/item?id=45656335 before we merged the threads)
zahlman 1y ago
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?
- denhamparry 1y ago
  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.

TealBLAHAJ 1y ago

The scary part isn’t the bug — it’s how fragile the patching process becomes once a crate goes unmaintained.

hsbauauvhabzb 1y ago
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.
- cozzyd 1y ago
  In principle "traditional" curated Linux distro package systems will patch stuff even if upstream is unresponsive.
  - hsbauauvhabzb 1y ago
    Sorry I should have clarified that I was referring to language based systems (cargo, pip, npm, etc). But you do raise a good point, it’s less about the concept of package management and more around the point of curation and central security guarantees / policies / procedures. In theory RHEL package management system could have similar problems to cargo or npm, but they are much better funded and thus managed.
  - ajross 1y ago
    In practice, not principle. Virtually every non-trivial upstream package in debian/fedora/arch/whatever has at least a handful of distro-specific patches. Sometimes they're just configuration, sometimes they're distro-maintained security fixes, etc... But people exercise those features regularly and distros are not shy about maintaining software. It's a very different world from "We Just Ship What They Give Us" in npm/cargo/etc...
- BobbyTables2 1y ago
  I really hate it when various packages expect users to add their custom repo. Especially for something where I don’t care about updates. Feels like every little thing should be in its own docker container with limited filesystem access. Of course that is a whole lot of trouble… The dependency trees in cargo/pip also greatly bother me. VS Code extensions are also under appreciated. Some turd makes a “starter pack” for rust/python/etc with a great set of common extensions… plus a few that nobody has heard of… Over time, they reach 50k-100k downloads and start to appear legit… Excellent way to exfiltrate trade secrets!!!

arresin 1y ago

From my experience abandoned repos is common in rust. Why is this?

hunterpayne 1y ago
I suspect because a lot of Rust library projects are just clones of a project (usually in C) translated to Rust. This is a good way to learn Rust. However, after you learn it, why maintain it? There isn't really much incentive. Add to that the politics of the Rust ecosystem and it causes churn in the dev population. I suspect there are other reasons too. There is a cost to fad languages being used. Replicating the ecosystem of libraries around a language is a huge job. Its rare that a language ever gets the same size and quality ecosystem as say C or Java. But the fans of the language will try. This leads to a lot of ported projects and a small number of devs maintaining a huge number of projects. That's a recipe for abandonware. I suspect a lot of student projects too which is also likely to do the same.
aDyslecticCrow 1y ago
I personally suspect it's an effect of the over reliance of the package manager approach to software development that rust and a few other languages use, which itself is an unintended to consequence of a well designed library import system. Languages where importing a library is hard, libraries tend to grow quite large. Large libraries have larger backing, more established development and security protocols. When OpenCV, TinyUSB, Numpy, nimBLE start to struggle, it's easier to notice and companies relying on them may step up to fork, maintain of fund its continued use. Languages where importing and creating a library is easy, we see small atomic packages for small utility programs, over large libraries. This spreads the software supply-chain wider, into smaller teams of maintainers. If the same amount of code is fractured over 50 small libraries maintained by 1-3 people each, the likelihood of one or two becoming abandoned grows. I've been a bit weary about the dependency and package manager approach more modern languages use. It trades convenience for some pretty scary supply-chain attacks.
- normie3000 1y ago
  I haven't seen this perspective before but it's a very elegant explanation for why e.g. npm is so much scarier than maven. I wonder if safety could be improved a little if private package management was easier than throwing things out in public.

jedisct1 1y ago

The state of the Rust crates ecosystem https://00f.net/2025/10/17/state-of-the-rust-ecosystem/ https://00f.net/2025/10/17/state-of-the-rust-ecosystem/

huflungdung 1y ago
[dead]

woodruffw 1y ago

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!) [1]: https://github.com/astral-sh/tokio-tar/security/advisories/GHSA-j5gw-2vrg-8fgx https://github.com/astral-sh/tokio-tar/security/advisories/G...

greatgib 1y ago

I'm so confused, I was thinking that we were rewriting everything from C to Rust because Rust was a "safe language" preventing vulnerabilities...

woodruffw 1y ago
To the best of my knowledge, nobody has ever seriously claimed that Rust (or any other general purpose programming language) can fully prevent logic errors. Rust's advantage is that it can prevent logic errors from becoming memory safety vulnerabilities (and separately, its type system makes some - but not all - classes of logic errors more difficult to introduce).
ajross 1y ago
This doesn't appear to be a memory safety bug. It's a data handling error, and the "RCE" in question is that the tar code can be fooled by a malicious tarball into writing files with arbitrary permissions at arbitrary paths (which is... actually something all tarballs can do, so I'm not really following why this is being treated as severe). But to your point: yes, it's a good example about how security bugs live at all layers of the stack and that being checked against memory corruption does nothing to prevent you from writing bugs in the semantic space.
- SoftTalker 1y ago
  iow it's a bug that can corrupt your data, but it does it safely.
kobebrookskC3 1y ago
if it was in c, who knows how many memory corruption bugs would be found before they stumbled upon this...
- whatevaa 1y ago
  If it was C, 99% it would have been an code execution.
- 1y ago

lvass 1y ago

Why didn't crates.io maintainers apply the patch themselves? NPM does meddle with packages when an incident happens like they did with left-pad.

woodruffw 1y ago
I think that would be pretty disruptive, and would break some assumptions around crate integrity that are deeply held. My understanding is that the left-pad incident is not directly analogous, since it involved restoring a deleted package rather than modifying an extant package.
eviks 1y ago
Do you have a more relevant example of meddling besides a binary block/publish?

alexzenla 1y ago

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!

whatevaa 1y ago

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.

__s 1y ago
Not inherent to format. Issue is just header parser ends up reading file contents, so putting tar file as file contents confuses things It'd be like putting zip in zip

hulitu 1y ago

> Tarmageddon: RCE vulnerability highlights challenges of open source abandonware And where is the RCE part ?