Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tarmageddon: RCE vulnerability highlights challenges of open source abandonware

edera.dev

Post reply on HN
Print view View original

1–10 of 59 posts

Re: Tarmageddon: RCE vulnerability highlights challenges of open source abandonware

#4

Post by goldsteinq »

denhamparry wrote: post #2

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

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”?

Re: Tarmageddon: RCE vulnerability highlights challenges of open source abandonware

#5

Post by denhamparry »

goldsteinq wrote: post #4
denhamparry wrote: post #2

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

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 ma…

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?

Re: Tarmageddon: RCE vulnerability highlights challenges of open source abandonware

#6

Post by goldsteinq »

denhamparry wrote: post #5
goldsteinq wrote: post #4

Earlier quoted context omitted.

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 ma…

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.…

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)?

Re: Tarmageddon: RCE vulnerability highlights challenges of open source abandonware

#7

Post by denhamparry »

goldsteinq wrote: post #6
denhamparry wrote: post #5

Earlier quoted context omitted.

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.…

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)?

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.

Re: Tarmageddon: RCE vulnerability highlights challenges of open source abandonware

#10

Post by hunterpayne »

arresin wrote: post #8

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

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.

Post reply on HN