Hi, all
I'd like to know how Rust is safe language even if developer is careless or malicious.
So, as in the title, Is it possible to write a highly security-critical code without using the 'unsafe' keyword?
Thank you
Safe Rust gives you memory safety (e.g. no use-after-free) unless a dependency has a bug in their unsafe (or there's a compiler bug).
That doesn't mean "Rust code is can't have logic errors that compromise security" or "careless use of unsafe also has memory safety" or "malicious developers can't do harm".
No language can automatically supply security, prevent logic errors, or protect you from malicious developers.
That's its own question, not the same question.
But -- assuming you mean can a highly security-critical crate be unsafe-free -- sure, it's possible.
(The question and this answer are both too vague to mean much though.)
12 Likes
Yes, you are right.
My question was very vague.
So To more clarify my question,
Highly security-critical code means: it can cause a kind of exploitable bug and does not include logical issue
For example.
char buf[8];
memcpy(buf, user_input, strlen(user_input));
That's a common memory safety bug -- a potential buffer overrun. Rust prevents those as long as you don't use the unsafe keyword.
More generally it prevents what is called undefined behavior (UB) in C/C++, including data races.
4 Likes
Right, Rust prevent that bug and also UAF, DoubleFree, and more.
So I'd like to know is there are any types of vulnerabilities that Rust cannot prevent, aside from logical issues.
I'm a big fan of Rust, so I'd like to introduce Rust to other people. But I'm not sure, Could I say something like, "If you write code in Rust without 'unsafe', your only security consideration would be logical problem"
I think it would be more accurate to say that Rust prevent security vulnerabilities that are due to UB (mainly memory safety and data races). It does not prevent any other types of security vulnerabilities. So your question is actually: are all other security vulnerabilities caused by logic errors? Security problems are varied, so I would be hesitant to say that.
To clarify on data races -- these are prevented by Rust, but other race conditions are not.
4 Likes
Well, Rust certainly can't save you from side-channel timing attacks, etc.
If we restrain to "memory issues". Then you need to deal with memory leak (may caused by cyclic dependency), and dead-lock, and out of memory ofc. These problems will not cause a data security issue, but may introduce deny of service.
7 Likes
Sure, for example the classes of errors that no language can prevent. Side channel attacks are one obvious example.
Another obvious example is stuff that is outside the control of the language (eg. human factors, leaked credentials, insufficient security of the physical hardware running your code, vulnerabilities in a non-Rust cryptography library, etc.)
No. Due to the existence of the aforementioned category of bugs, no language can give you such a guarantee.
3 Likes
It's funny how everyone discussed the fine-grained details without addressing “an elephant in the room”
Yes.
No. Just… no. Simply… no.
There were many attempts to use language-level safety as security border and this just never works (PHP, Java and others).
Compilers are complicated beasts, there are bugs (almost hundred of them just right now) and you may never 100% trust them to sensibly process untrusted code (except if you use them as in pNaCl or BPF: run the untrusted compiler in a sandbox, then verify the result for safety without ever trusting compiler itself).
The end result: while “safe” languages work perfectly to catch accidental mistakes of the developers using them to sandbox malicious code is 100% foolish.
They are just not designed for that, period.
2 Likes
The simple answer to that is no. It is impossible to do input/output without using unsafe. Why? Because to do I/O you need to make system calls to whatever operating system you have, or you have to actually read and write hardware I/O devices directly. Neither of which the Rust type checker and borrow checker know anything about.
However that is not show stopper. Your program can be free of unsafe itself and make calls to I/O functions that wrap unsafe. We trust the author of that I/O stuff has done the right thing. Or if we are fussy we can those small parts ourselves.
Having unsafe free application code of course does not stop one writing code that is insecure. After all you can always forget to check a password, or implement encryption badly or a million other logical errors. There is no way a compiler can know your intent and so no way it can tell if you have implemented it correctly.
It is possible I guess that Rust allows some odd memory misuse errors but I'm pretty sure they would be classed as compiler bugs that need fixing.
2 Likes
It is possible. Deleting of files is "safe" in Rust:
// danger: don't run this
std::process::Command::new("rm").args(["-rf", "/"]).spawn()
It's also possible to crash a Rust program in safe code:
fn infinite_recursion() {
infinite_recursion();
}
Rust safety is only for catching mistakes. It's not a sandbox. It's not a security barrier.
7 Likes
Due to a compiler bug, you can currently write unsafe code that results in UB in safe Rust as showcased by the cve-rs crate.
But this is rather unlikely to happen just by accident.
1 Like
On the topic of writing highly security critical code in Rust, there is a great talk by Jon Gjengset from RustNationUK earlier this year: Towards Impeccable Rust
2 Likes
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.