-sys crates are just bindings and doing something else in them is highly suspect. The rest I recognize as being owned by a Rust maintainer like alexcrichton or rustlang itself.
With crates.io using GH as its IdP, I think there would be much farther reaching consequences to account pwning in that scenario. I agree, though, that the security model for crates.io is only as strong as the weakest link there, and would pray someone like Alex is using physical tokens or the like for his MFA and can't be conned by a well-crafted email.
sys crates are also mostly generated and lack a lot of eyeballs. Sneaking something into the build.rs of a sys crate would not be difficult and would land in the builds of everything downstream of it.
I had pondered the same thing about other package ecosystems in the past, in general. Now with the benefit of hindsight we can comfortably say that the absence of known (!) attacks doesn't really say anything about how relatively difficult an attack would be. Are -sys crates, or build script attacks, particularly potent? Who knows. When I did a cursory search, the only attempts I saw were at runtime rather than build time[1]. Which raises a good point; pwning a developer machine or CI box with a build script may be quite valuable, but if you might get that and prod with a runtime exploit, is the build time exploit that much more valuable? Guess it depends! (Of course, I personally think having at least optional build time sandboxing is even better than hoping it won't be valuable to attack.)
Of course, crates.io has surely had some malicious packages. (I'd assume it isn't all that unlikely there could be some undiscovered right now; it's definitely large enough for something like that to slip under the radar, even if it is relatively small compared to say, NPM.) But, I think it really hasn't had its XZ backdoor moment, its left-pad, where you really get to see how well it does or doesn't handle a serious challenge. Since I have actually not published on crates.io, I'm not really sure how the security posture is, but if it's more similar to other programming language repositories than it is to Linux repos, I dunno exactly why it would be hard to believe a high-level compromise is possible and could slip in (really, anywhere, be it a build script or otherwise.). Of course, "would not be difficult" is all relative. I'm sure many of these attacks are not really all that simple, but a lot of them aren't exactly groundbreaking either. It was well executed and took quite a lot of time, sure, but there wasn't all that much about the XZ backdoor that was novel. (Except maybe the slyness with which the payload was hidden in test files. That was pretty cool.)
ou can defend a claim that literally anything is a supply-chain risk from this logic. Don't use vim to edit your config files because you don't have any way to know that someone couldn't slip a "reflections on trusting trust" compiler attack into clang so that your MacOS binary distributed by homebrew detects when you're editing an npm.json and exfiltrates your ssh keys so that they can push rogue builds!
Yes. Your comment reads to me as a defense of the comment above the one you replied to:
>>> sys crates are also mostly generated and lack a lot of eyeballs. Sneaking something into the build.rs of a sys crate would not be difficult and would land in the builds of everything downstream of it.
>> Surely that's why we see evidence of all these build script attacks, since it's so easy?
> Now with the benefit of hindsight we can comfortably say that the absence of known (!) attacks doesn't really say anything about how relatively difficult an attack would be.
Given that you were responding to a critique of what seems to be fully conjecture with the argument that we don't know for sure that it's not feasible, it's not clear to me why that wouldn't be a sufficient defense of any claim of a potential vulnerability without regard for merit. You don't propose any alternative than ignoring the only hard evidence we have, so although you might not have intended it this way, it's not clear to me what discussion you could expect to happen with that standard of evidence other than throwing up our hands and saying everything is screwed.
We do in fact see them a lot. Typically they target Python or Node because those ecosystems are much more popular than Rust. But build.rs provides exactly the same opportunities to attackers for Rust.
No, we don't. We see build system attacks, such as injecting malicious scripts into their CI and getting malicious code into the artifact for use at runtime. You don't see someone doing a drive-by PR to a `setup.py`.
Not a drive-by PR, but once a package is compromised it often does spread to its reverse-dependencies via mechanisms like setup.py at build time. There was case like this with setup.py less than two months ago: https://www.stepsecurity.io/blog/forcememo-hundreds-of-githu...
Lots of npm supply chain attacks propagate at build time via post-install hooks, too.
The issue here isn't Alex Crichton going rogue, but rather, some malware stealing his credentials to use them to publish more malware in crates.io
In this sense, the more well known and upstanding Rust developer, the higher the risk they will be targeted by such operations