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

41–50 of 59 posts

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

#41

Post by alexzenla »

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!

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

#42

Post by eqvinox »

kibwen wrote: post #29
aDyslecticCrow wrote: post #11

Earlier quoted context omitted.

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

But Rust doesn't have an abundance of small/atomic libraries. This is describing NPM, not crates.io. Rust doesn't have the same culture as Node.

There might be fewer small crates, but I've still seen massive dependency lists. Case in point: tokio. How many "related" crates do you deal with for various features? 5? 50? It's not great.

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

#43

Post by pjmlp »

kibwen wrote: post #29
aDyslecticCrow wrote: post #11

Earlier quoted context omitted.

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

But Rust doesn't have an abundance of small/atomic libraries. This is describing NPM, not crates.io. Rust doesn't have the same culture as Node.

Say what?

Any Rust project has endless crates scrolling up the screen.

It has exactly the same culture as npm, which is no wonder, because many folks adopting Rust come from Web background, not C and C++.

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

#44

Post by whatevaa »

kobebrookskC3 wrote: post #36
greatgib wrote: post #24

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

if it was in c, who knows how many memory corruption bugs would be found before they stumbled upon this...

If it was C, 99% it would have been an code execution.

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

#46

Post by kibwen »

pjmlp wrote: post #43
kibwen wrote: post #29

Earlier quoted context omitted.

But Rust doesn't have an abundance of small/atomic libraries. This is describing NPM, not crates.io. Rust doesn't have the same culture as Node.

Say what? Any Rust project has endless crates scrolling up the screen. It has exactly the same culture as npm, which is no wonder, because many folks adopting Rust come from Web background, not C and C++.

No, this is mistaken. A crate is both rustc's unit of compilation and Cargo's unit of dependency. Feel free to lament this conflation all you like, but what it means is that the common pattern is for library authors to publish large crates that are internally split into smaller crates for better compilation parallelism. This just isn't a problem by any metric; it doesn't increase your trusted computing base. That's not at all the same problem as NPM has with its web of frivolous micro-dependencies.

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

#47

Post by __s »

whatevaa wrote: post #45

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.

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

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

#48

Post by pjmlp »

kibwen wrote: post #46
pjmlp wrote: post #43

Earlier quoted context omitted.

Say what? Any Rust project has endless crates scrolling up the screen. It has exactly the same culture as npm, which is no wonder, because many folks adopting Rust come from Web background, not C and C++.

No, this is mistaken. A crate is both rustc's unit of compilation and Cargo's unit of dependency. Feel free to lament this conflation all you like, but what it means is that the common pattern is for library authors to publish large crates that are internally split into smaller crates for better compilation parallelism. This just isn't a problem by any metric; it doesn't increase your trusted computing base. That's n…

It is surely a problem given the cumulative time everyone waits compiling them distributed across Rust users.

Also if it wasn't a problem, articles like this wouldn't exist,

https://tweedegolf.nl/en/blog/104/dealing-with-dependencies-...

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

#49

Post by woodruffw »

pjmlp wrote: post #48
kibwen wrote: post #46

Earlier quoted context omitted.

No, this is mistaken. A crate is both rustc's unit of compilation and Cargo's unit of dependency. Feel free to lament this conflation all you like, but what it means is that the common pattern is for library authors to publish large crates that are internally split into smaller crates for better compilation parallelism. This just isn't a problem by any metric; it doesn't increase your trusted computing base. That's n…

It is surely a problem given the cumulative time everyone waits compiling them distributed across Rust users. Also if it wasn't a problem, articles like this wouldn't exist, https://tweedegolf.nl/en/blog/104/dealing-with-dependencies-...

This is backwards: per GP, the cumulative time would be greater if there were fewer crates, because of how incremental and parallel compilation work in Rust.

(This doesn’t mean Rust doesn’t have a dependency proliferation issue, only that the way you’re substantiating it is misleading: it’s like saying that C has a dependency proliferation issue because libfoo goes from having 3 source files to 5 source files between releases.)

Post reply on HN