Are Rust crates secure?

[BatmanAoD]

It’s that old thing of preventing 80% of the damage by finding solutions to 20% of the problems.

That seems entirely reasonable. However…

Medium level is certainly possible since you would not need to spend a large amount of effort to ensure it.

I don’t see how this statement could possibly be true, especially in the current context of responding to Peter Bertok’s questions.

…how would anyone know to continue trusting crates, and all of their transitive dependencies? What if a “crate turns bad” because someone new takes over its maintenance, a password leaks, or someone just stops updating it and critical vulnerabilities go silently unpatched?

2FA, signing, etc. would not solve these problems, and I don’t see any other way to “ensure” the trustworthiness of crates without “a large amount of effort.”

My point about Turing-completeness is that full static analysis of program behavior is not possible in principle, and any form of algorithmically-enforced trustworthiness via 2FA, signing, etc. cannot prevent malicious attacks of the kind described by Peter Bertok. In particular, social attacks (e.g. phishing, typo-squatting) would be difficult to prevent, and the hypothetical “crate turns bad” scenarios seem essentially impossible to prevent.

[DrizztVD1]

I’d prefer to respond here, if you don’t mind:

Security fence for crates

[mbrubeck]

[Moderator note: A few comments hidden. Please try to keep posts on-topic, and in most cases use flags or contact the moderators if you feel there is inappropriate content, rather than engaging with it in-thread.]

[pyk]

This is very helpful thread, so many ideas that I can learnt from this thread.

One of the thing, that I think it missing here is the idea to run all crates in secure-sandboxed environment by default, with no network access and no file system access. This will make sure that all crates are do what supposed to do, for example: linter lib should be just read and write and cannot access any network.

As a rust users, I want to run all my projects in sandboxed environment with crates-level permission to access network or file system. And yes, it needs to be combined with other ideas such as 2FA, signed etc to create a more security on the crates distribution level.

[bgeron]

One of the thing, that I think it missing here is the idea to run all crates in secure-sandboxed environment by default, with no network access and no file system access. This will make sure that all crates are do what supposed to do, for example: linter lib should be just read and write and cannot access any network.

It’s a nice idea but it cannot be done in a cross-platform way. Even for a single platform this is a difficult research question. It’s basically only possible if you want to ban unsafe by default, which rules out a large number of useful crates. I don’t think that it would then actually be useful for many people.

[dcarosone]

Somewhat tangential to the thread of conversation so far (which might be welcome), some relevant issues about cargo were raised in this excellent blog post about reviewing code for unsafe:

Auditing popular Rust crates: how a one-line unsafe has nearly ruined everything

Key conclusion and constructive suggestions (at least with respect to cargo):

Rust has no mechanism for propagating security updates through the ecosystem. I was surprised to find that Cargo does not alert you when you’re using an outdated library version with a security vulnerability, and crates.io does not reject uploads of new crates that depend on vulnerable library versions, and does not alert maintainers of existing crates that their dependencies are vulnerable. A third-party tool to check for security vulnerabilities exists, but you’ve never heard of it and you have better things to do than run that on all of your crates every day anyway.

[DrizztVD1]

It’s a nice idea but it cannot be done in a cross-platform way. Even for a single platform this is a difficult research question. It’s basically only possible if you want to ban unsafe by default, which rules out a large number of useful crates. I don’t think that it would then actually be useful for many people.

Sorry buddy, but I’m going to call you out on what I perceive as too negative about the difficulty of security. Unless I am wrong and you have the hard evidence as to why it “cannot be done in a cross-platform way”. So, respectfully, I challenge you to back that up with reasoning and proof, this as well: “Even for a single platform this is a difficult research question.” Because, I’m taking the opposing side here and calling it out as untrue. (Hint, I have hard evidence to an actual, mass-deployed real-world system that I was involved in creating that meets the outcomes that @pyk suggests here in a related problem area. And it catches these things with 99% accuracy btw).

[darrenldl]

(Hint, I have hard evidence to an actual, mass-deployed real-world system that I was involved in creating that meets the outcomes that @pyk suggests here in a related problem area. And it catches these things with 99% accuracy btw).

Is it possible to get any pointers to said system(s)? I am very curious about the possibility of sandboxing languages with no runtime at crate/package granularity. To my limited understanding, sandboxing at crate level would entail at least a runtime, since normal sandboxing kits can only work at process-by-process basis?

I am only aware of Java, Racket and similar ones that have builtin support of sandboxing, but they all possess a runtime, thus my confusion.

[DrizztVD1]

Is it possible to get any pointers to said system(s)? I am very curious about the possibility of sandboxing languages with no runtime at crate/package granularity. To my limited understanding, sandboxing at crate level would entail at least a runtime, since normal sandboxing kits can only work at process-by-process basis?

Note that the qualification of “no runtime” is not made in the claim. I presume that is inferred because the cross-compilation makes dynamic (during runtime) evaluation tricky. That is not applicable to “single platform” though.

Dynamic cross-compilation evaluation is tricky, but static evaluation, while less accurate, still works well. Meaning that you analyse the resultant binary for a) strings analysis b) library calls analysis c) a combination of other methods that are more use-case specific (like Ransomware will always try to contact a controlling server using (often) domain name generation until it finds a hit (response). This is because the attacker needs the symmetric key or he cannot reverse the encryption after the ransom is paid. Very similar means will be used for gaining a backdoor into compiled code for remote exploitation.

Unfortunately the 99% accurate behavioural analysis malware detector I worked on (as a team effort mind you) is fenced off and costs a couple of hundred thousand dollars as part of a security suite for corporations.

Obviously I don’t have all the answers though and the discussion on the implementation details is ongoing at https://internals.rust-lang.org/t/security-fence-for-crates/8005/35?u=drizztvd

I have the same question about the crate granularity analysis there - I have some ideas on how to do this there. (it is where the similarity of my prior experience versus this problem set ends).

I should note that I’m also being cheeky with my challenge to @bgeron (but trying to stay on the right side of respectful). I don’t mean to shoot all his comments down, just the ones that come with “cannot be done” and “basically only possible” - which is a great way to set yourself up for being proven wrong in life. My managers thought the malware analzer wil work like… 60% of the time, and not work at all on new classes of malware. Then, I think it was WannaCry, came out and bam!!! the behavioural analsis with trained deep neural net caught it dispite being a ‘new class of malware’ according to the definition used by the system (I could be mistaken on the name of the malware, but the idea remains true).

[DrizztVD1]

This is very helpful thread, so many ideas that I can learnt from this thread.

One of the thing, that I think it missing here is the idea to run all crates in secure-sandboxed environment by default, with no network access and no file system access. This will make sure that all crates are do what supposed to do, for example: linter lib should be just read and write and cannot access any network.

Glad you find it useful.

I’m replying on your implementation-specific discussion here: https://internals.rust-lang.org/t/security-fence-for-crates/8005/35?u=drizztvd

Discussions on “is security doable” and “should security be on by default” discussion can stay here as it relates to users.

[bgeron]

I am only aware of Java, Racket and similar ones that have builtin support of sandboxing, but they all possess a runtime, thus my confusion.

In addition to having a runtime, they also all lack unsafety. If you can find a language with crate-level security and unsafety, I would be very interested to see it. I think it’s plain impossible without a near-complete overhaul of the userland/kernel boundary.

I don’t think you can give mathematical proofs of these things, and I’m not exactly sure what you’re asking for. Basically the way the world resolves these kinds of research questions is someone proposes an approach that might work, and then others try to find flaws in this. I try to stay up to date on the state of security, and I’m pretty confident of what I said. If you have unsafety, then you can write to RAM, change machine code (or ROP the stack), and pretty much get around any security that your language pretended to offer. Indeed, the recent smallvec announcement shows that it’s not so hard to get arbitrary code execution.

Of course, I’m assuming conventional machine architectures and OSes. (Because we want this to be cross-platform.)

By the way, when I say “security” I mean much more than heuristic antivirus-level security.

[darrenldl]

Note that the qualification of “no runtime” is not made in the claim.

Apologies for the incorrect terminology/assumption on my part, I referred runtime as
the virtual machine of programming language, rather than the one in static vs. dynamic sense. My statement about “no runtime” was referring to Rust having no such VM, or at least minimal compared to other managed programming languages.

Unfortunately the 99% accurate behavioural analysis malware detector I worked on (as a team effort mind you) is fenced off and costs a couple of hundred thousand dollars as part of a security suite for corporations.

Ah makes sense, since I think I would have heard of it at least if it’s published publicly.

I should note that I’m also being cheeky with my challenge to @bgeron (but trying to stay on the right side of respectful). I don’t mean to shoot all his comments down, just the ones that come with “cannot be done” and “basically only possible” - which is a great way to set yourself up for being proven wrong in life.

IMO the disagreement between you and @bgeron only comes from the differing perspectives/premises. I think he’s arguing on the strictly general sense in that the problem is not solvable universally in all contexts, while you’re arguing for meaningful security sense where 99%(or whatever threshold) is acceptably good. That’s my very coarse interpretation anyway.

[darrenldl]

I don’t think you can give mathematical proofs of these things, and I’m not exactly sure what you’re asking for. Basically the way the world resolves these kinds of research questions is someone proposes an approach that might work, and then others try to find flaws in this

By the way, when I say “security” I mean much more than heuristic antivirus-level security.

Yep this kinda confirms my above reply in that you two(@bgeron and @DrizztVD1) are just speaking with different premises.

From formal verification point of view, you can’t guarantee security in all cases all the time, or analyse then guarantee any properties/behaviours of arbitrary code in general, since you need to solve the halting problem first etc. Having solved a problem in this context means it’s fully covered - it is impossible you would ever find an exception to the solution under the assumptions attached. Thus it cannot be solved since you cannot guarantee any property fully w.r.t. fully arbitrary code. This is what @bgeron is suggesting I think.

From practical security point of view, having something that mitigates most threats and produces very little false positives/negatives(depending on how you’re defining the problem) is good enough. And my understanding is that solving a problem in this context/field means having a solution, but it is not necessarily the case that the solution works universally, but the solution works effectively in general. This is what @DrizztVD1 is suggesting I think.

[bgeron]

So like an antivirus for crates.io?

Maybe. Maybe not. I’m afraid it might weed out the script kiddies but not sophisticated determined teams of a couple people, while giving false confidence that the ecosystem is secure.

I need to think about this.

[DrizztVD1]

IMO the disagreement between you and @bgeron only comes from the differing perspectives/premises. I think he’s arguing on the strictly general sense in that the problem is not solvable universally in all contexts, while you’re arguing for meaningful security sense where 99%(or whatever threshold) is acceptably good. That’s my very coarse interpretation anyway.

Yes, I tried to address this previously, but seem to have failed, so I’ll post here my second attempt at it made on internals:

I think there are more ways to stop this type of malicious code insertion than auditing. I’ll just repost here a previous part of a post to explain:

(High) safe from most government attacks

(Medium) safe from experienced hackers working mostly alone

(low) safe from script kiddies.

Audits can fall under the High level. Medium level is reached by using cool-off periods for updates, so that the hacker in question can only carry out his attack after some period of time (helps reduce the attack surface but not eliminate it of course).

Academic-proof security is not high or even Extremely high-security level it is Absolute security level. Medium level can be practically implemented without that much effort, as explained on the internals thread.

Well, look, I can walk you through a couple of quantum cryptography Absolute-level proofs that I learnt from a Caltech professor. But I can tell you, it’s painful (for me at least). And then, halfway through the course we threw away the Absolute-level proofs and went to something like Extreme-Level proofs (not completely unbeakable, but likely to take 100 years of work to break if at all). Fortunately Medium level is an entirely different ball game

Now remember that my target here is to do some kind of security (as in better than nothing).
More specifically:

It’s that old thing of preventing 80% of the damage by finding solutions to 20% of the problems.

Medium level security can be reached by only fixing 20% of the security problems, I can almost guarantee you that. (The reasons are given on the internals thread)

By the way, when I say “security” I mean much more than heuristic antivirus-level security.

btw, Heuristics don’t work anymore (as in they’re terrible). AI with deep neural nets work quite well when done correctly.

Ah makes sense, since I think I would have heard of it at least if it’s published publicly.

The work was purely an implementation of existing ideas. We (I) scraped all the literature that I could find (and I had access to Stanford’s academic library at the time), then we rated the implementations based on execution time impact, time to implement, and accuracy, and ended up using something like 10% of the published work on this.

We brainstormed new ideas to try, but poked holes in them so fast that we just gave up and specifically chose to not add anything that has not been peer-reviewed and poked at, because doing non-peer-reviewed security is one common way to mess up security badly. Bitdefender has a similar implementation now, they also claim 99% accuracy, so I think they followed much the same procedure, but I have not looked at their stuff because they came out with it 2 years after our project started.

[DrizztVD1]

This blog post here explains my point further:

Auditing popular Rust crates: how a one-line unsafe has nearly ruined everything

and it is fresh off the press. The points there show exactly what I mean by Medium level security. We can do Absolute level proofs here all week long and not get anywhere, when in fact we could just follow through on the authors work and get useful stuff done real fast that have a lasting impact on the community with relatively little effort. I want to make a bet here that it will be less work than the NLL borrow checker to reach Medium-level security for Rust crates.

[bgeron]

By the way, are we focusing in this thread on

(1) insecurities put in crates on accident by crate authors,
(2) insecurities put in crates on purpose by crate authors,
(3) ownership of crates being maliciously perverted?

I think it used to be (1) and (3) but the sandbox comment suggested defending ourselves against (2). Number (2) is really really hard to defend against, if you want anything resembling Medium level security.

I get the impression that (3) is being addressed on the internals forum now.

I’m really in favour of audits and stuff, which is (1). We’re on level 0 right now, but I think we can get most important crates up to Medium.

Security levels Low, Medium, High

The classification of security goes something like:
High) safe from most government attacks
Medium) safe from experienced hackers working mostly alone
low) safe from script kiddies.

[DrizztVD1]

From practical security point of view, having something that mitigates most threats and produces very little false positives/negatives(depending on how you’re defining the problem) is good enough. And my understanding is that solving a problem in this context/field means having a solution, but it is not necessarily the case that the solution works universally, but the solution works effectively in general. This is what @DrizztVD1 is suggesting I think.

+1

That is the target. Academic proofs just make me tired… I’m probably the wrong guy to discuss such things with.

Like Elon Musk says (paraphrasing): Do not let perfection get in the way of making something that works. Aka, nothing is perfect, but perfection is not the expectation for any real-world system.

Slightly off-topic: did you know that Civil Engineers target a “death rate limit” for a construction? Meaning that, it’s kinda ok if a huge site construction leads to… about 10 deaths over its lifetime (including effects of pollution from the site etc)? This is because with heavy machinery operation and construction, zero casualty rates are practically impossible. In short, none of us would have a house to live in if perfect safety was the bar for doing construction. The same applies to security.

[bgeron]

Academic proofs just make me tired… I’m probably the wrong guy to discuss such things with.

It doesn’t have to be academic proofs… Android does a very reasonable job of keeping different apps apart, no academic proofs! But that approach doesn’t work for Rust unfortunately.

But let’s focus on getting some level of security against accidental security holes.

[DrizztVD1]

(1) insecurities put in crates on accident by crate authors,
(2) insecurities put in crates on purpose by crate authors,
(3) ownership of crates being maliciously perverted?

(3) is the 2FA discussion… but that discussion is a cluster… right now (seriously). I’d like to stay productive in our threads.
(2) has a POC here: https://internals.rust-lang.org/t/security-fence-for-crates/8005/35?u=drizztvd
(1) can be caught by the methods in the Medium article that I linked to.

(2) is kinda hard, but ultimately worth it. But here the locked front door policy works: lets find a lock for the door of security of Rust crates. Yes, someone is going to forget to lock the door on their way out in the future, and we can try (when that happens) to prevent it. But, right now the lock mechanism is missing and the windows at ground level don’t have bars on. And I mean by default, because not having the features on out of the box is really not going to solve the problem. (and getting newcomers to learn from the guidelines and book with updated security principles explained with how and why).