Hacker News Reader

Comment by pdpi | Hacker News Reader

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.

1 - http://cglab.ca/~abeinges/blah/everyone-poops/

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

View on HN

> 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!

Prepooping only applies to unsafe Rust. There are a few soundness bugs though: https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is...

Reply on news.ycombinator.com