I'm looking to introduce Rust to my team and am looking for answers to some security evaluation questions.
Does rustc implement things like stack guards, control flow integrity, ASLR, and DEP? What other security features are put in the final executable?
From what I saw at how rustc invokes MSVC on windows, it already looks like high entropy ASLR, and DEP are enabled by default, but I want to make sure with the community knowledge.
It uses LLVM backend and system linker, so any features available to clang are available to rust as well.
But the main one is, of course, that the compiler ensures that any safe code can't have the kind of bugs that could be exploited: references are statically checked that they point to valid objects that were not released yet, all array access has bounds checking inserted, and stack is checked for overflow. So if you stick to safe code for code that parses and verifies untrusted input, you greatly reduce the possible attack surface (to just bugs in the compiler or standard library).
As @jan_hudec mentions, Rust's biggest security feature is the use of advanced static analysis and its type system to prevent memory safety bugs, along with things like automated bounds checking.
ASLR is an OS feature and DEP is a CPU feature, both are orthogonal to the language/compiler used.
Thanks for the replies @jan_hudec@jethrogb . The language level features that guarantee memory safety in Rust is one reason I'm advocating for its use and something I'm really excited about. However, unsafe code is something we will have to touch eventually given the area we work in. From a Defense-in-Depth perspective, that is why it's nice to have some additional security features for when programmers like me make mistakes.
@jethrogb do you know if there is any documentation on Rust using stack guards? I would like to be able to cite something like an RFC or an issue or something 'official'.
Does anyone know if things like Control Flow Integrity is in the pipeline for rustc somewhere?
The out-of-box security of Rust is something that was discussed recently. The conclusion was that, while rustc has some strong security guarantees, Cargo remains an area with much scope to pull common mitigations in as standard.
I can point to one discussion on the matter, mostly focused on identifying the first steps (test/validate/evaluate the TUF model and use RustSec tools as linked in this thread):
The current state of Rust crates from a security standpoint (the state is quite good):
I'm currently spending an hour or two every now and then incorporating Cuckoo malware sandbox into a fuzzing/feature checking system to identify direct code injections from malicious actors. The idea is to merge later with:
The unsafe code guidelines need to have a dichotomy: Performance and Safe Performance. I'm hoping to get some C/C++ -like guidelines on security included there, both from extensive publications and from people with code auditing experience:
It's early days for Rust on the security front. I'd suggest asking yourself how much effort you'd be able to get people to put into 'trimming the lawn' so to speak. Meaning, try to sell people on the productivity enhancements of Rust, and then convince them to contribute to fixing up the security even more. As you would know, not having security on by default and out-of-the-box is about equivalent to not having that security features at all. RustBelt is doing a lot on the compiler security proofs side: https://plv.mpi-sws.org/rustbelt/popl18/
Unfortunately, academic security proof means zip-all if it's not applied by everyone (on by default), as any red-teaming white hat hacker has discovered with much glee. And easy-to-use default security is still some way off on Rust based on initial crates security audits.