Proposal: Security Working Group

[gbutler]

“Ooo, I see, it prevented me from pointing a loaded multi-barrel machine gun at my own foot and my friends’ heads”

I vote for this as the new motto for the Rust front-page: Let's reword front page claims

[arielb1]

I think that finding a way of having Programming-Language-guaranteed constant-time and memory-zeroing code, although an interesting an important task, is mostly a big PL-research and implementation task.

The “application” security concerns in Rust (i.e., making sure Cargo is secured, finding out good coding practices and secure libraries for Rust code, managing vulnerability disclosure, etc.) feel less “researchy” and more “supervisory”, and should probably be done in parallel (I think that there is a fairly small amount of overlap between the people who are interested in working on both tasks).

[wesleywiser]

Forgive me if I missed an earlier post on this topic, but I don’t see anything in this thread regarding implementing or leveraging platform mitigations. A user on the user forums was interested in this topic recently. A cursory glance at the Rust documentation revealed no information about what (if any) kinds of mitigation are available to Rust programmers. I’d love to see the security working group take point on this and implement and document what mitigations are available on which platforms. For examples: ASLR, stack canaries, safe stack, control flow integrity, DEP, W^X, etc.

[arielb1]

I think that an RFC issue such as https://github.com/rust-lang/rfcs/issues/2533 is a more permanent place to talk about the details of secret handling than this thread.

[DrizztVD]

The “application” security concerns in Rust (i.e., making sure Cargo is secured, finding out good coding practices and secure libraries for Rust code, managing vulnerability disclosure, etc.) feel less “researchy” and more “supervisory”, and should probably be done in parallel (I think that there is a fairly small amount of overlap between the people who are interested in working on both tasks).

Yes, because, the day a major security break happens at a company due to a failure in the security proofs and not because of the failure in applying said proofs is the day I’ll eat my hat.

So, by all means, continue with the cool researchy stuff, just be aware that (I’m being very generous here) less than 2% of exploits will target those stuff. The other 98%+ will target faulty implementations and faulty humans using said implementations.

Computer security at the application level can be separated into levels:

(Very High) Safe from all attacks regardless of resources for the next 80 years.

(High) safe from most government attacks

(Medium) safe from experienced hackers working mostly alone

(low) safe from script kiddies.

Research targets making coding secure to above Very High level. Security consultants in the field work on Medium and High levels mitigations. To put it in an analogy:

Here we see the completed part of the bucket representing the brilliant work researchers do to provide a solid and secure framework. The unfinished part of the bucket represents that fact that between the lecture halls and the field, 90% of the research work is nerfed/forgotten/misapplied. The security consultant is paid to explain to the software devs that the tools they are using to program (tools are represented by the bucket), will not hold water without a dedicated effort to address the security for each and every application individually.

That brings us to Rust Security WG. We cannot leave whatever the researchers do rotting in the academic journals or applied to 1% of applications. The research work needs to be built into the ecosystem to become invisible the way that bricks are invisible in a building - you know they are doing their job by the fact that nobody notices them.

The security WG will only succeed if both sides work together to make sure no figurative ‘stave’ of the bucket remains forgotten since computer security is a game of The Weakest Link. And, people on one side will need to become familiar with the other side to ensure the whole ecosystem is balanced. That way, the lowest stave of the bucket will be at least Medium level for the Rust ecosystem, default on and out-of-the-box.

[DrizztVD]

Forgive me if I missed an earlier post on this topic, but I don’t see anything in this thread regarding implementing or leveraging platform mitigations.

Yep, although the examples you mention are rustc implementations, but it is a good point. Other platform mitigation examples can be found here.

All those mitigations you mention are to prevent chained memory exploits. Which shows you how terrible C/C++ coding is at memory management. The interesting thing is that, if you can ensure memory management is done 100% correctly, all those mitigations become unnecessary.

Continuing from my earlier discussion with the platform mitigations as example:

Since Rust has been shown to provide muuuuch better memory management, everything else security-wise suddenly becomes more important. It’s the equivalent of living in a bad neighbourhood with a flimsy front door (C/C++), then you went out and got a 2-inch thick front door forged of Mithril in the fires of Balrog, and suddenly the fact that the windows don’t have bars and the roof tiles are loose becomes a much bigger problem. Rinse and repeat with more Balrog huffing and puffing and you’ll eventually end up with a rather nifty house that no wolf would ever be able to blow over. And, we’re just past the front-door upgrade at the moment.

It should be clear, however, that a 10-inch front door (piling more and more security on rustc) won’t solve the windows-without-bars problem in this analogy.

[ZerothLaw]

I propose that discussing specific, arcane security topics should not be done in this thread. It will be done in the spaces setup for the WG, once those are done.

[Manishearth]

Good call. cc @frewsxcv @killercup @Manishearth @PaulGrandperrin from https://github.com/orgs/rust-fuzz/people

Certainly interested in helping out here, though at this point I’m unclear as to what the scope of this WG is – this discussion seems to be going everywhere.

(perhaps “security WG” is too broad a title for what your original intent was?)

[wesleywiser]

Yep, although the examples you mention are rustc implementations, but it is a good point. Other platform mitigation examples can be found here .

AFAIK, most of the things I mentioned are actually not supported by rustc.

All those mitigations you mention are to prevent chained memory exploits. Which shows you how terrible C/C++ coding is at memory management. The interesting thing is that, if you can ensure memory management is done 100% correctly, all those mitigations become unnecessary.

Obviously the situation in Rust is much better but, as I understand it, many of these guarantees go away when you use unsafe {}. At that point, it’s up to you to enforce type, memory, and thread safety just as it is in C\C++.

It should be clear, however, that a 10-inch front door (piling more and more security on rustc) won’t solve the windows-without-bars problem in this analogy.

Sorry, I wasn’t suggesting this should be the only responsibility. Security in my mind is very much a “both-and” rather than an “either-or”. We need guarantees from the language and we need defense-in-depth mitigations in the compiler and we need cryptographic primitives and we need to audit the ecosystem, etc.

[DrizztVD]

AFAIK, most of the things I mentioned are actually not supported by rustc.

Not sure how much of it is currently implemented. I suppose I meant those would be implementations related to rustc. It remains to be seen how high the priority of memory protection features should be. The problem is that embedded does not, and likely will not, support ASLR or DEP or many other things. Same goes for IoT. This was an earlier post on some of it:

What security features are implemented by rustc?

Obviously the situation in Rust is much better but, as I understand it, many of these guarantees go away when you use unsafe {} . At that point, it’s up to you to enforce type, memory, and thread safety just as it is in C\C++.

It’s certainly possible to program with 100% memory safety in C/C++, the same way that it’s possible to do a skyscraper tightrope walk. It’s another question whether one should attempt that. Proper Unsafe Coding Guidelines can ensure that the tightrope comes with a handrail in the case of Rust though. Also, unsafe marks where exactly code auditing should be focused and makes it easier to audit for that reason. Lastly, targeted testing and fuzzing of crates does allow for automated discovery of memory problems in the code. If unsafe does not occur too many times in the crate, and with enough added work on these tools, one can be reasonably assured that test-fuzzing will hit all the possible code paths.

If everyone had read and remembered (https://www.amazon.com/Art-Software-Security-Assessment-Vulnerabilities/dp/0321444426), C/C++ would be much safer. Problem is, it takes two months+ of full time reading and practising to meaningfully work through those books. ( I tried doing it in 3 weeks - didn’t get far enough). So that means almost no-one in industry who isn’t paid for that sort of thing is going to work through it. That means that unsafe should be a last resort - and crates.io should detect and flag indiscriminate use of unsafe automatically to allow correcting this code early on. The idea is that rustc+cargo should keep programmers from accidentally walking into the ‘here be dragons’ parts of coding unless someone intentionally chooses to jump over the handrail - just like the borrow checker does. This implies work needs to be done to separate and warn/error on ‘unsafe unsafe’ and not ‘safe unsafe’. DEP/ASLR etc. should then really be the second tier of defence, since needing them means the attackers have already broken the front door down. But, on Windows/Linux such second-tier mitigations should still be used wherever possible.

Sorry, I wasn’t suggesting this should be the only responsibility. Security in my mind is very much a “both-and” rather than an “either-or”. We need guarantees from the language and we need defense-in-depth mitigations in the compiler and we need cryptographic primitives and we need to audit the ecosystem, etc.

I like that statement. I was more continuing from my earlier posts on pointing out the fact that, traditionally, far too much effort is expended on a handful of theoretical security features, while leaving a whole bunch of previously invented features unimplemented or not easily implementable. And this is coming from someone who’s spent disproportionate effort in pursuing quantum cryptography studies, mind you. So call it speaking from the far side of personal experience.

[mvduin]

I think that finding a way of having Programming-Language-guaranteed constant-time and memory-zeroing code, although an interesting an important task, is mostly a big PL-research and implementation task.

It seems pretty straightforward to solve this from a PL point of view: have a way to mark data as being “secret”, make any expression that depends on a secret be secret except for some way to explicitly mark secret data as no longer secret (e.g. the final ciphertext). Have it be the compiler’s responsibility to ensure secrets are wiped from temporary locations (stack, registers) once no longer needed and to refrain from producing code whose timing depends on a secret.

The big problem is that support for these things is (afaik) absent in LLVM and there’s no way to enforce these things from a higher level if they’re not supported at a lower level.

[frewsxcv]

If fuzz testing is within scope of the WG, I’d be happy to be part of this. I’ve been hoping for a security or cryptography WG to form, so thanks for initiating the discussion @joshlf!

[ZerothLaw]

So that means almost no-one in industry who isn’t paid for that sort of thing is going to work through it. That means that unsafe should be a last resort - and crates.io should detect and flag indiscriminate use of unsafe automatically to allow correcting this code early on.

I’m sorry, but there needs to be some consideration for FFI, which I would estimate is where a lot of the unsafe code usage is.

You can’t keep coming down on unsafe generically without considering FFI functionality.

[ctz]

I’m interested in participating in this WG.

[jleni]

I would like to contribute to this WG.

cargo-audit to run on crates.io index

This would be definitely a great idea.

[derekdreery]

My idea was that security infrastructure would be under the group’s purview, yes, although there’s of course the question of how much we can bite off in practice. @bascule has expressed interest in this group, and I’d imagine that he would be interested in taking that on as part of the group’s work.

This point may have been made already, so apologies if it has:

Security is trust. So what you are asking for is a way to trust crates and the language infrastructure. It’s important to remember this - many people trust SSL even for some CAs I find dubious at best. If there is a security team vetting packages, you trust that team (unless you vet everything yourself).

So my suggestions would be

• No central committee responsible for vetting crates, but instead a peer review system, where if a crate sees interest (maybe a certain number of downloads, or dependent crates), it gets flagged for review. People are registered as reviewers, and a number of them are randomly chosen to review the crate. Once sufficient people have reviewed a crate, it gets a reviewed sticker. If anyone has concerns, there is some mechanism to resolve them (todo think of a mechanism). This is then repeated for new releases, debounced to some time period.
• It is possible to only use reviewed/validated crates, this also disallows future versions until they are validated.
• There is some mechanism to no only yank versions of crates, but mark them as vulnerable. Then when running cargo run/build/etc, you get told if you have any vulnerable packages. I think I saw this in npm. It might be possible to do this with yanked crates (you get a warning if you are using a yanked version).
• Keep pushing fuzzing/testing/removing unsafe where possible. It would be good to have a WG that pushed this. It isn’t necessarily a programming issue, might be more of a human/best practice issue.

I think it is a very good idea overall to have a WG, mostly just to keep everyone thinking about the security aspect of everything, including design decisions. The rust core team are already very good on security (e.g. security@rust-lang.org, https://www.rust-lang.org/en-US/security.html). You would have to work out how a security WG would fit in with that.

[derekdreery]

Totally agree - security is mostly psycology/best practice/the right people knowing the right things.

[DrizztVD]

I’m sorry, but there needs to be some consideration for FFI, which I would estimate is where a lot of the unsafe code usage is.

You can’t keep coming down on unsafe generically without considering FFI functionality.

Agreed. One can only dream of a world where all libraries are written in Rust. Given that code maintenance appears to be up to an order of magnitude easier in Rust compared to C, this is theoretically possible. Until then, however, unaudited C/C++ used in Rust calls remains in the “Low level” security and nothing relying on it can be guaranteed to not be exploitable by someone in their basement with Kali Linux. That’s just logically the only answer I see. Either pay for a code security audit or rewrite foreign code in Rust within secure Rust guidelines.

[DrizztVD]

No central committee responsible for vetting crates, but instead a peer review system, where if a crate sees interest (maybe a certain number of downloads, or dependent crates), it gets flagged for review.

I’d aggree that vetting is everyone’s job, not just a security group. I would, however, advocate for a web-of-trust type implementation that works in parallel with the crowdsourced security model you suggest. This means that an individual that is part of that web of trusted individuals can review a crate, and then confer a “badge” onto the crate that gives the crate something like “Rust Security Web of Trust approved” status. A crate does not have to have this status, but it would be good if they do.

These badges should be able to be applied by other entities as well. For instance, if a for-profit starts security auditing crates, the crate user can request the crate to be reviewed by this company and the badge “Security company X approved” added to that crate. This is so that individuals funding official crate audits can personally benefit from such audits while the rest of the community can re-use the code that was audited and marked as such. There should be a mechanism to register such badges before use of course. Some of these other entities can also enter the Rust Security Trust Web if their reputation with its members becomes good enough, which means they will be able to assign more than one security badge if they want ("Rust Security Web of Trust as well as their own).

The rust core team are already very good on security (e.g. security@rust-lang.org, https://www.rust-lang.org/en-US/security.html ). You would have to work out how a security WG would fit in with that.

I’d say the split in focus should be proactive vs reactive. Traditionally, an internal security group works to prioritise known weaknesses in existing code and eliminate these weaknesses somewhat in the order of importance. The Security WG would deal with providing a sufficient set of tools that cover the base of a complete security solution for other coders to use to gain a reasonable level of assurance of the security of the code they use as well as what they produce themselves. The complete range of tools required should be agreed upon and the order of priority of each decided on to some extent.

As such, the Security WG should aim to minimise the number of security fixes they do themselves and always aim to educate and guide the Rust programming community to program securely from the start, as far as is possible.

[DrizztVD]

The areas to look at is:

1. Secure Unsafe vs Insecure Unsafe Guidelines,

2. Automated code testing and security fuzzing

3. Reliable Cryptographic implementations

4. Some reasonable level of code security auditing

5. Concise education for Rustaceans on security best practises

6. A mechanism to inform and encourage usage of updated code as well as a means to rapidly and effortlessly (hopefully) patch applications running code in which a security flaw was found.

What am I missing? Where should the FFI concerns fall under?