Hi all,

In yesterday's lecture I was asked if using a systems programming language like Rust could help avoid some of the security bugs that are often seen in C code. I mentioned that it can indeed help – but it's important to note that it's still possible for Rust programs and libraries to abruptly abort, segfault, or display undefined behaviour.

By default when you access an array element in Rust, Rust performs a "checked" access – it makes sure the element you're accessing is within bounds, and aborts if it is not.

However, if you know that the element is within bounds, you can also make an "unchecked" array access, in which case Rust skips the bounds check. This is typically done for performance reasons – if you're making many array accesses within a tight loop, all the checks will slow your program down, so you may choose to make unchecked accesses instead. The problem is, if your reasoning is wrong, and the array index was actually out of bounds, then you've caused undefined behaviour, with much the same results as in C.

(There are also other reasons why you might have to use "unsafe" or "unchecked" features of Rust – common reasons are because you're writing your own optimised data structures, or need to interact with C code.)

An example of a security vulnerability arising from undefined behaviour in Rust code is this one, listed on the (US) National Vulnerability Database. There's no need to read it unless you're interested, but the vulnerability arises because arguments to one Rust function weren't checked for validity, and could results in out-of-bounds array access. (The "fix" is that the function is now flagged as "unsafe", with documentation stating that it's the caller's responsibility to use it in the correct manner.)

Also, even if memory problems are avoided, it's still possible to cause security vulnerabilities in Rust code due to poor design or mistakes in implementation (e.g. this issue) – memory-safe languages can prevent some problems, but they can't turn a fundamentally insecure design or bad implementation into a good one.

Cheers!

Arran