Of course it is possible. If you get your hands on the binary itself there's nothing that a good reverse-engineer will not be able to do.
Point however is, if you have a SaaS which uses Rust, the chances for triggering a buffer underflow / overflow exploit are zero.
As for other aspects of security, Rust makes no special effort there. The main win for using Rust is to eliminate the most widespread bugs (the memory safety ones) from the get go. Everything else is still fair game and has to be paid proper attention to.
> the chances for triggering a buffer underflow / overflow exploit are zero
Doesn't the mere existence of unsafe make this untrue? From a quick google I can see at least one[1] so the chances are definitely a lot higher than zero
The GP is either being incorrectly absolutist, or left out an important qualifier: "In safe Rust, the chances of <insert memory safety problem here> are zero."
But that is also absolutist. Instead, you might say, "In safe Rust, the chances of <insert memory safety problem here> are zero, modulo bugs in the compiler."
But that's not quite the fully story either. So instead, you might say, "In safe Rust, the chances of <insert memory safety problem here> are zero, modulo bugs in the compiler or any dependencies or any other uses of 'unsafe' in your application."
And maybe that's still not quite it. So let's try again: "In safe Rust, the chances of <insert memory safety problem here> are zero, modulo bugs in the compiler, any dependencies or any other uses of 'unsafe' in your application and any other platform specific tricks for arbitrarily rewriting memory used by your process."
That probably covers it. But it's a mouthful. It's probably best to avoid saying the chances of anything are zero. Instead, the key value add of Rust is that it flags areas of code that permit introduction of UB for easier auditing, and also enables building safe---for all inputs---abstractions for others to use. But humans are fallible, so there is and always will be an opportunity to fuck something up somewhere. What Rust gives you over something like C or C++ is a way to make assumptions that are more fine grained than, "I trust that every line of code written in the transitive dependency chain is free of UB."
Thanks, that last bit clears it up for me. I've never touched Rust but write C++ everyday so don't really know much about what is guaranteed vs. what is less likely due to borrow checking/compiler verifaction
What I simply meant was "it's quite hard to introduce memory non-safety in Rust in a normal everyday work". But your explanation is definitely much more precise.
I suppose that depends on your definition of normal everyday work though, if you're developing device drivers or something that needs to write into shared mmap'd memory or whatever `unsafe` is something you're going to need all the time (from my 0 rust experience understanding?)
Right, I figured as much. There is so much misunderstanding about what 'unsafe' is and does that it's really really important to be precise about it when your audience isn't Rust programmers.
I imagine what they're alluding to is that it seems like most of the security bugs are memory-safety related. The number is about 70%, and has been replicated independently at a number of places.
Calling unsafe libraries automatically makes the calling code unsafe by definition. You cannot have a 100% safe language that also interacts with its (unsafe) environment in any way.
The language needs a way to express the lack of safety of an external library in order to clearly isolate it from the safe code sections. In Rust that's the unsafe block.