Are Rust crates secure?

[gbutler69]

saying that the things mentioned here are similar shows that you must have missed a number of things.

Or it means we have different ideas of what “similar” means.

[DrizztVD1]

For that reason, I think the discussion of these things has to move beyond specific technical issues and move more into the realm of what kind of “organization” needs to exist, how it would be funded, how it would be staffed, how it would coordinated and comply with industry approve standards and auditing processes approved and/or recognized by the insurance and auditing industries. Just talking about specific technical aspects of things like buffer over-flows, unsafe code guidelines, 2FA, crate signing, etc., while useful, won’t get you anywhere you need to be to have meaningful “trust” (meaning the insurance companies can assess and value the risk to their satisfaction)

Well, that would be part of the topic we have going here. The best solution may be to take these discussions, and the posts not related to 2FA on the internals thread, and use them to argue for a Security team for Rust as part of the 2019 roadmap. Since most of their work will be on crates, they would also be the Crates team-in-one. That way, patreon and other sponsoring can occur for the money part of the discussion.

The consensus that we need to reach here, however, is whether the security of crates at the moment is such that such a security workgroup is needed.

I don’t agree though that buffer overflows are not relevant here. While I have not tested it, it’s probable that the borrow-checker will severely limit both local and remote code execution in reasonably-well designed code. Right now C/C++ needs to be excellently designed to meet the same level of security. Hence, the memory safety makes the crate security so much more important, else we throw away a very useful result flowing, once again, from Rusts borrow checker.

[gbutler69]

I don’t agree though that buffer overflows are not relevant here.

Yes, but, I never said anywhere that it wasn’t relevant. I specifically said:

Just talking about specific technical aspects of things like buffer over-flows, unsafe code guidelines, 2FA, crate signing, etc., while useful, won’t get you anywhere you need to be to have meaningful “trust”

That is a long way from saying it isn’t relevant. I would kindly ask you to try to avoid mischaracterizing what others have said. It weakens the overall discussion.

[DrizztVD1]

It is relevant to building trust in Rust’s security. Is that mischaracterization?

The premise is that Rust has an underlying reason why, after crates are shown to be secure, individuals using those crates are able to maintain the same level of security as those crates. Memory safety is that reason aka the borrow checker.

[DrizztVD1]

The consensus that we need to reach here, however, is whether the security of crates at the moment is such that such a security workgroup is needed.

I think so.

[bgeron]

I think the state of crates currently is “good enough”. It would be nice to have a more systemic approach to security involving vetted crates, code reviews, etc., but I think the people resources aren’t there. Vetting even 1% of the current crates, even one version of those 1% of crates, is an absolutely immense effort. It also stifles innovation a bit, by preventing uptake of new crates which may have a much better API but which may not yet have been reviewed.

[TomP]

Perhaps this could start as an informal interest group in which those of us with relevant background could participate. I too am new to Rust, and find myself already devoting too much time to these forums (fora?). I’ve been attempting to get other former colleagues with Medium and High white-hat security experience to look into Rust. A request from me for them to participate in such a group might provide the needed impetus.

[DrizztVD1]

Continuing, mostly, here: https://internals.rust-lang.org/t/security-fence-for-crates/8005?u=drizztvd

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