[pdimitar]

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.

[clappski]

> 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

[1] https://github.com/servo/rust-smallvec/issues/252

[burntsushi]

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."

[clappski]

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

[pdimitar]

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.

[clappski]

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?)

[pdimitar]

Agreed, that is true.

Nobody is saying Rust is completely bullet-proof: if anything, our current hardware doesn't allow for it.

But it gets very close.

[burntsushi]

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.

[sweeneyrod]

I don't think memory safety bugs are the most widespread kind at all, unless you add the qualification "in languages with manual memory management".

[steveklabnik]

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.

That is of course a very different thing!

[pdimitar]

Yeah, seems I messed up some words. :(

But yes, I meant the majority of the security bugs indeed.