Lab 6: Safety & Security

In this lab we will walk through the ways in which Rust’s design facilitates safety, how Rust’s safety guarantees interact with its low-level programming capabilities, and how Rust’s definition of safety interacts with our understanding of security in low-level programming.

Safe Rust vs. Unsafe Rust

Rust is actually split into two languages: Safe Rust and Unsafe Rust. So far in this class we’ve been working with Safe Rust, but in this lab we’re going to get into Unsafe Rust.

The key difference between Safe Rust and Unsafe Rust is that in Safe Rust, the compiler checks your work. It makes sure that nothing you write violates the rules Rust has. In Unsafe Rust, the compiler doesn’t check everything, and instead just assumes you’ve checked the code yourself.

Unsafe Rust is used when you have code that is safe, but which the compiler can’t prove is safe. (Remember, there is a difference between truth and provability, as we discussed in a previous lecture.)

Unwinding into Rust from foreign code or unwinding from Rust into foreign code. Rust’s failure system is not compatible with exception handling in other languages. Unwinding must be caught and handled at FFI boundaries.

Safety and Security

Failures of safety as defined above can and do lead to real world security issues.

For this lab, I want you to find a real world security flaw that could have been prevented with the memory safety guarantees Rust provides, and then write about it. Submit a PDF report on it to me via email by 4pm next Thursday. The report should describe the vulnerability, and the memory safety issue it connects with.

The CVE and CWE databases are a good place to start looking for vulnerabilities.