I think it's fair to have a high level of confidence in freedom from arbitrary code execution, buffer overruns, double frees, etc.
It does not, however, follow that it will be free from leaks of secrets. There are plenty of ways to leak secrets which don't involve the program leaving its envelope of defined behavior. No language is free from that.
Buffer overruns and double frees are things you can have a high degree of confidence won't happen. Even then, the bindings to libsodium are, by necessity, unsafe, and bugs can hide there.
Also, all you need to get remote execution is bad user input validation surrounding some instance of std::process::Command.
Though such cases have been few and far between, soundness bugs have shown up in Rust, and some oddities in the way RAII works have lead to the notion of Prepooping your pants[1] to avoid use-after-free bugs.
Rust is a phenomenal language, and one I'm placing a lot of faith in, but it provides only very specific guarantees and it's unwise to assume it will protect you from more than it actually does
> Though such cases have been few and far between, soundness bugs have shown up in Rust, and some oddities in the way RAII works have lead to the notion of Prepooping your pants[1] to avoid use-after-free bugs.
There's a huge difference between checking your program for memory model violations, and checking the compiler for correctness.
Given a program written 99.9% in safe Rust, and a minimum set of unsafe stubs (trivial enough to prove) to access outside world (syscalls), you can assume you're safe against RCE. The holes are more likely in the supporting logic outside your program - kernel, dynamic loaders, network stacks, debug/trace interfaces, row hammer, etc.
> Rust is a phenomenal language, and one I'm placing a lot of faith in, but it provides only very specific guarantees and it's unwise to assume it will protect you from more than it actually does
I do agree with this point, though. It guarantees you will not escape the envelope of a specific memory model and defined behavior, up to the boundary of "unsafe" blocks, and assuming the runtime environment is not interfered with externally. You still need all those externalities to be secure, and it does nothing for leakage through side-channels.
> Given a program written 99.9% in safe Rust, and a minimum set of unsafe stubs (trivial enough to prove) to access outside world (syscalls), you can assume you're safe against RCE. The holes are more likely in the supporting logic outside your program - kernel, dynamic loaders, network stacks, debug/trace interfaces, row hammer, etc.
Right - and, if the description for the project had put it in those terms, I'd have felt the project deserved more of my trust. My problem was precisely with the dismissive tone in which it says "It's written in Rust so I'm immune to all these things", while not actually backing that statement with a half-decent justification for why Rust would help.
I've actually toyed around with implementing time safe operations in rust. We have the advantage that few implementations of rust exist. So in contemporary rust I can just disable inlining and introduce a function call. Not something that's safe to do in c, as far as i know. Now the compiler guys will never vouch for this behavior but once you narrow your targets things get interesting with security. Intel and Arm are both interesting platforms with a lot of quirks!
Though I would love to agree with you, Java also promised to fully protect us from arbitrary code execution. In some ways even stronger than Rust. But as we all know Java has been riddled with code execution bugs.
Now I wouldn't dare accuse Rust developers to be as terrible at writing secure code as the average K&R worshipper, and unlike the JVM most (all?) of Rust is actually written in Rust I hear, but I wouldn't flat out claim there won't ever be an arbitrary code execution vulnerability in a Rust project.
> But as we all know Java has been riddled with code execution bugs.
Most of those are of the form "malicious code delivered as Java applet can break out of the JVM sandbox". That is, they crucially rely on running untrusted code. By contrast, the threat model here involves attackers subverting existing, trusted code. Memory safety holes in Rust overwhelmingly rely on bizarre carefully crafted code that nobody would accidentally write.
There are some exceptions: Java is affected by serialization issues along the lines of the Rails YAML vulnerability, for instance. But most of those don't apply to Rust either for various reasons.
Another source of Java bugs is improper input sanitation when untrusted input eventually feed into various interpreters like embedded JavaScript or SQL. That, of cause, can happen with any language, but at least with Rust it is much harder to accidentally call into some framework that exposes an interpreter capable of arbitrary code execution.
True enough, definitely with untrusted code your surface is that much larger. What I remember from the few JVM bugs I looked at is that they were always at points where the JVM would call into the operating system or otherwise interact with native code. I would imagine Rust code might be vulnerable at those same points, though obviously much less easily.
There are basically three major classes of Java code execution bugs:
1) Bugs in native code (generally image processing, compression, etc). This code tends to be derived from existing libraries, and so shares common vulnerabilities.
2) Bugs in sandboxing when running untrusted code. Java's sandbox model is fundamentally flawed and I don't believe it can ever be secured.
3) Executing untrusted external user input within the JVM context, e.g., by evaluating external data using your internal scripting language that has access to the JVM or relies on JVM sandboxing.
Of those:
1) Not much you can do, but issues are relatively rare.
2) Can be avoided by not running untrusted code in a JVM-enforced sandbox (applets are dead, sorry).
3) You'll be fine if you steer clear of libraries that even go near eval() of untrusted user input. The culprits here are serial offenders due to architectural/design issues, and are easy to avoid (e.g. Apache Struts.)
> but I wouldn't flat out claim there won't ever be an arbitrary code execution vulnerability in a Rust project.
If you note the OP, he expressed it in terms of "high confidence" not a "claim there won't ever be an arbitrary code execution vulnerability in a Rust project". Which would be absurd. And it's also as good as it gets: you can't avoid vulnerabilities.
I'm actually curious now – is it possible to deliberately introduce an RCE vulnerability into Rust code with `#![forbid(unsafe_code)]`? Has anyone done it?
Well this particular project this comment thread is about does not actually implement any cryptographic operations, those are all done by libsodium[1] a project written in C.
Imagine now it is possible to construct an argument to those libsodium functions that satisfies the constraints of the Rust wrappers, but still manages to crash libsodium and execute some part of the argument, which is not unheard of since libsodium is written in C and it operates on blobs of data.
Now the only mistake the implementor of thrussh has to make is to allow for that input to be passed into the rust libsodium wrapper through the protocol implementation.
It does not, however, follow that it will be free from leaks of secrets. There are plenty of ways to leak secrets which don't involve the program leaving its envelope of defined behavior. No language is free from that.