SAN FRANCISCO, CA - In the wake of a devastating supply chain attack in the npm registry that left millions of enterprise applications compromised and billions of user records exposed, developers across the JavaScript ecosystem expressed deep sorrow today, lamenting that such a crisis was completely unavoidable.
“It’s a shame, but what can you do? This is just the price of building modern web apps,” said Senior Frontend Engineer Mark Vance, echoing the sentiments of a community that completely relies on a 40-level-deep nested tree of unvetted packages maintained by pseudonymous strangers to capitalize a single string. “There’s absolutely no way to foresee or prevent someone from taking over a long-abandoned utility package and injecting a crypto-miner into every production build in the world. It’s just an act of nature.”
As someone who’s built a career in Rust, it is 100% susceptible to an attack like this. The community is just generally paranoid enough to avoid depending on super niche packages.
Even so, Cargo still doesn’t have code signing and crates.io doesn’t have 2FA. They just barely rolled out email alerts for new crates being published with your API key.
And there’s dozens of single-author crates that are depended upon by millions of lines of code, any one of which could easily be a vector in a supply chain attack. In fact there have been attempted supply chain attacks against crates.io, but to my knowledge they’ve all relied on typo-squatting.
We’re definitely overdue for a major attack.
Today I had to build and install an application using Crates. It recursively pulled 700 other packages and gave me a gut feeling comparable to testicular torsion. I don’t care how paranoid the community is, it only takes one careless maintainer to
node-ipcorleft-padan entire dependency tree.Crates.io does support trusted publishing for GitHub and gitlab. It’s not much, but it’s Honest work.
… I which it supported forgego
It’s not enforced though, and there’s no way as a consumer to see how a crate was published.
To be extremely fair, crates.io has a huge maintenance bottleneck because AFAIK it doesn’t even have a single dedicated developer. But that’s definitely a big part of the problem.
The Rust Foundation is really just not pulling in enough revenue to support the project properly. They really ought to figure out more revenue streams than just sponsorships and donations.
Nice. I’ve always been paranoid of typo squatting but never knew it had an official name or people that implement it. Thanks for the share
I guess one benefit is rust development often doesn’t use bleeding edge version for everything, where you pull the entirety of crates.io through your machine when you open your IDE. From what I’ve seen most projects use == versions and lock files.
I don’t know enough about rust though. Could an attacker change historical crate versions to a payload and then cargo pulls them because they changed? Or will cargo only pull an update if you change to a different version on your machine?
Cargo does not respect lockfiles by default, AFAIK. You need to explicitly pass the --locked flag.
When you
cargo installa binary, it ignores lockfiles. If you clone a project and build it, it respects theCargo.lockthat was checked in.You can’t overwrite previously published versions.
Application projects are recommended to check-in the
Cargo.lockwhich pins dependency versions but you can always just runcargo updateat any time which automatically upgrades all dependencies to the newest version allowed by theCargo.toml.Some projects get around this by pinning the dependency in the
Cargo.toml(using=) or by vendoring all their dependencies, which is a huge pain in the ass.That sounds better and worse. An attack could persist past one specific version without anyone noticing for a bit.